Subject: checking for new mail in all mailboxes

From: David Feldman <[email-masked]>
Date: Thu, 24 Jun 2004 14:01:09 -0400

I am a bit of a newbie in all respects, but am learning about both IMAP  
and c-client in the course of developing a client application. After  
looking through the documentation I have what I imagine is a pretty  
basic question: How does one (at both the IMAP command and c-client  
level) check for new mail efficiently in all a user's mailboxes at  
once?

Thanks.
--Dave

------------------------------------------------------------------------ 
--
David A. Feldman
User Interface Designer
http://InterfaceThis.com

-- 
------------------------------------------------------------------
 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: Thu, 24 Jun 2004 12:02:09 -0700 (PDT)

On Thu, 24 Jun 2004, David Feldman wrote:
> How does one (at both the IMAP command and c-client level) check for new mail 
> efficiently in all a user's mailboxes at once?

The short answer is: you can't.

The longer answer is:

Identify a set of mailboxes which merit further probing, and focus your 
checking on them.

In a strictly "check all mailboxes" environment, do a LIST and note which 
mailboxes come back with \Marked status (if you're paranoid, then choose 
the mailboxes which don't have \Unmarked status).  Then do a STATUS on 
each of these to check them further, or just SELECT them if the user wants 
them opened.

Alternatively, have a discrimination between "incoming" mailboxes and 
mailboxes which are strictly archive.  Don't even consider the archive 
mailboxes, which for most users greatly overwhelm the number of incoming 
mailboxes.  If you are a reasonable number of incoming mailboxes, then 
just have all of these mailboxes SELECTed in separate IMAP sessions; this 
is the most efficient, best real-time, and least-costly way to monitor a 
set of mailboxes.

Put another way; 5 IMAP sessions monitoring 5 mailboxes is less costly 
(often *MUCH* less costly) than repeatedly probing those 5 mailboxes in 
one IMAP session.  Sessions are cheap, especially if you use the IDLE 
command.  Polls are not cheap, especially with mail stores that oblige the 
server has to parse the enter mailbox to satisfy a STATUS.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.

---

From: David Feldman <[email-masked]>
Date: Thu, 24 Jun 2004 16:04:40 -0400

> mailboxes, which for most users greatly overwhelm the number of  
> incoming mailboxes.  If you are a reasonable number of incoming  
> mailboxes, then just have all of these mailboxes SELECTed in separate  
> IMAP sessions; this is the most efficient, best real-time, and  
> least-costly way to monitor a set of mailboxes.

That becomes tricky in multiple-client situations, though, doesn't it?  
If the user accesses his mail from several locations (and particularly  
if he leaves the client open in more than one), messages may be added  
to an "archive" folder manually in one client that the other client  
would need to find out about.

> (often *MUCH* less costly) than repeatedly probing those 5 mailboxes  
> in one IMAP session.  Sessions are cheap, especially if you use the  
> IDLE command.  Polls are not cheap, especially with mail stores that  
> oblige the server has to parse the enter mailbox to satisfy a STATUS.

Might this method run into problems with providers that limit the  
number of simultaneous connections from a given IP?

Thanks again,
--Dave

---

From: Mark Crispin <[email-masked]>
Date: Thu, 24 Jun 2004 17:38:15 -0700 (Pacific Daylight Time)

> That becomes tricky in multiple-client situations, though, doesn't it?

It depends upon what you are trying to do.  If the client maintains its 
own copy of the mailboxes and thus needs to synchronize, then yes you have 
an issue.

If, on the other hand, the client just wants to know if there's new mail 
that it needs to show the user, the job is much simpler.

The whole point of IMAP is to keep mail on the server, and the client is 
essentially a user interface.  Some client authors can't get over the POP 
based idea of a message access protocol being a sort of reverse-SMTP.

> Might this method run into problems with providers that limit the number of 
> simultaneous connections from a given IP?

An ISP which does that is broken.  What if that IP is a shell system, with 
hundreds of people logged in?

-- Mark --

---

From: David Feldman <[email-masked]>
Date: Fri, 25 Jun 2004 08:40:34 -0400

> The whole point of IMAP is to keep mail on the server, and the client  
> is essentially a user interface.  Some client authors can't get over  
> the POP based idea of a message access protocol being a sort of  
> reverse-SMTP.

I don't want to start a flame war or something here, but it seems like  
the client-as-UI-only model is a good idea but not yet practical in  
many situations. Since many users are faced with (a) ISPs whose systems  
they might reasonably be less likely to trust than their own for things  
like data security and backup, (b) ISPs who don't give them enough disk  
space to store all their messages if they choose to keep most of their  
mail for archival purposes, and (c) situations where they may switch  
ISPs periodically and want to keep their mail interaction as is, the  
idea of keeping a master copy on one client computer seems like a valid  
one, practically if not in the abstract. I'm grappling with this issue  
now because I like IMAP and would like to switch my own accounts over  
to it, but at the very least the lack of support in most IMAP clients  
for situation (b) above prevents me: I would have to divide many of my  
mailboxes into an online "current" part and an offline "archive" part,  
whereas what I'd love to have is a single mailbox where older mail  
remains on the client only.

I suppose I'm a bit off topic at this point though...

--Dave