Aaron -
Your needs are common ones. Unfortunately, for the most part, they remain
unfufilled needs; but help is on the way (slowly...).
One realization that took a long time coming was that the proper place to
perform notification is not in message *access* (which is what IMAP does),
but rather in message *delivery*.
On many systems, the mail delivery software has no relationship to the
POP or IMAP server software. Often, the software is from entirely
different vendors. Since the IMAP server software is often not part of
the message delivery process, it has no good way of knowing that new
messages have been delivered other than by polling.
As you have noted, client-initiated polling is not cheap. It is not
substantially cheaper by specifying that IMAP should notify, and giving it
no other way than to do the work than by polling (albeit under the covers
where the client doesn't see it happening). Not surprisingly, IMAP server
developers who face this problem are not enthusiastic about IMAP being
given that mandate.
This does not necessary mean that there could not be some facility in IMAP
to request a notification, and perhaps even to receive the notification
and pass it on to the client.
What it means is that there needs to be a new service, which the
developers of mail delivery software will feel encouraged to implement.
Roughly, this new service would work as follows. When a message is
delivered, the facts of the delivery are passed to the notification
service which determines if there are any requests to be notified of such
a message (you don't want to spam someone with notification if he hasn't
asked for them!). If there is such a request, the notification service
transmits a notification to the requesting entity.
An IMAP client could be the "requesting entity". Then again, the
middleman could be eliminated by having the user's application request the
notification itself (maybe you want notifications but don't want to keep
your IMAP client running all the time). Personally, I feel that it is
best to have IMAP out of the loop, but I'm not adamant on that point.
Of course, in your environment, you're using dmail so all the code is
under my control. However, that would only provide for notifications for
people who use both dmail and UW imapd. Ideally, we would have a standard
that would not require a single vendor's (even if it is UW) solution.
As you noticed, none of the current mailbox formats used by UW imapd are
particular ameniable to doing poll-type notification. At least in part
this is due to legacy. However, with delivery-initiated notifications,
there is no need to do polling or to have special format considerations
for notification.
I actually developed a prototype version of a protocol and software that
did this, but that project got shelved. More recently, the IETF Lemonade
Working Group has considered the question of notification, and a hack (RFC
4146) to do this has actually been published as an RFC. They are actually
chartered to do this work, see item 4 of:
http://www.ietf.org/html.charters/lemonade-charter.html
-- Mark --
http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.
Si vis pacem, para bellum.
_______________________________________________
Imap-uw mailing list
[EMAIL PROTECTED]
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
