Subject: What's the Right Way to do imap xbiff?

From: Tim Culver <[email-masked]>
Date: Sun, 18 Jul 1999 21:04:06 -0400 (EDT)

Hi all,

I using c-client to add imap capability to xbuffy, and I'd like to
solicit some opinions.  Xbuffy is the same idea as xbiff, except that
it shows the number of "new" messages instead of just their
absence/presence, and is also willing to display the From: and
Subject: lines.

I've perused the archives of this list, and looked briefly at
comp.mail.imap, and I've noticed lots of talk about checking for new
mail, but I haven't seen anybody lay down the law for how a
lightweight, non-mail-client xbiff program should work.  I have
narrowed it down to three designs that seem reasonable to me.

First let me state my assumptions.

  a. xbuffy will have concurrent (though read-only) access with at
least one other client.  (For instance, I use emacs/VM, which
currently treats an imap server as a pop server.)

  b. xbuffy should minimize consumption of server resources.

  c. xbuffy is running on a unix-like system.

The possibilities:

  1. Use mail_search_full() to count unseen or recent messages.

  2. Start with mail_search_full(), then just ping for a while.  As
stream->nmsgs increases, assume these are unseen.  The new message
reports become inaccurate if you delete messages, but if you're
deleting messages you're probably not watching xbuffy so it doesn't
matter.  Every once in a while, mail_search_full() to correct the
approximation. 

  3. Use mail_status().  Don't mail_open().

I have seen Mark C. recommend against #3 on this mailing list.  My
current favorite is #2 as mail_ping() seems like the lightest-weight
c-client call.

Other issues... if your biff frequency is high enough, you should keep
the connection open; if low enough, you should open a new connection,
count, and close each time.  Where's the cutoff?  Highly
system-dependent, of course, but any wisdom?

Lastly, is it a security risk to cache a password in memory (under
assumption (c) above)?  I suppose I could kerberize xbuffy.  I could
also rewrite it as a Java application or Word macro.

Thanks for entertaining all my questions,
Tim Culver <[email-masked]>
-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Sun, 18 Jul 1999 18:50:05 -0700 (PDT)

You have misunderstood the recommendation.

The correct operation for a biff-type operation which does not use mail_open()
is to use mail_status().

HOWEVER:

It is absolutely wrong for a client to use both mail_open() and mail_status()
on the same mailbox at the same time.  Certain individuals incorrectly think
that mail_status() is the correct way to get the current status of a mailbox
which they have open with mail_open() -- not only is this incorrect, it is
horribly incorrect.

It is probably alright for a biff-type operation which uses mail_status() to
wake up every 3-5 minutes.  It should not do so more frequently; this is a
terrible burden to place upon a server.  Applications which do so anyway will
be ruthlessly hunted down and exterminated with extreme prejudice.

If a user really wants more frequent mail update, the correct thing to do is
to run an IMAP client and keep the mailbox open.  IMAP automatically provides
updates.  An intelligent biff-type application will stay asleep as long as an
active IMAP session exists to the mailbox, since the IMAP client should alert
the user of new mail.

---

From: Tim Culver <[email-masked]>
Date: Sun, 18 Jul 1999 23:17:21 -0400 (EDT)

>>>>> "mc" == Mark Crispin <[email-masked]> writes:

mc> The correct operation for a biff-type operation which does not use mail_open()
mc> is to use mail_status().

OK.  That makes sense.

mc> It is absolutely wrong for a client to use both mail_open() and mail_status()
mc> on the same mailbox at the same time.  Certain individuals incorrectly think
mc> that mail_status() is the correct way to get the current status of a mailbox
mc> which they have open with mail_open() -- not only is this incorrect, it is
mc> horribly incorrect.

Well, to defend "certain individuals," whoever they might be,
internal.txt doesn't mention this.  I figured it out from looking at
chkmail.c.  (It's not every day that one gets SIGUSR2, you know :-) )

mc> It is probably alright for a biff-type operation which uses mail_status() to
mc> wake up every 3-5 minutes.  It should not do so more frequently; this is a
mc> terrible burden to place upon a server.  Applications which do so anyway will
mc> be ruthlessly hunted down and exterminated with extreme prejudice.

Duly noted.  I'll think of some way to discourage this behavior.

mc> If a user really wants more frequent mail update, the correct thing to do is
mc> to run an IMAP client and keep the mailbox open.  IMAP automatically provides
mc> updates.  An intelligent biff-type application will stay asleep as long as an
mc> active IMAP session exists to the mailbox, since the IMAP client should alert
mc> the user of new mail.

That would be a very clever biff indeed!  The users I have in mind,
though, are people like me whose favorite MUA doesn't really support
IMAP.  VM, for example, knows about as much about IMAP as fetchmail
does.  

So perhaps there should be two modes of operation... open/search/ping, 
and status.

Thanks for your help,
Tim