On Sun, 30 Mar 2008, simon haywood wrote:
1. That emails will (should?) arrive to be read in my email client as soon
as they are sent - not after the next timed poll.
That assumes that there is infrastructure between the delivery system and
the IMAP server to accomplish that. That is not a good assumption.
If such infrastructure does not exist, then the server will poll
internally. That's what UW imapd does, at a one-minute interval.
This looks like something I don't have a full understanding of. Would you be
kind enough to direct me to some background reading?
I don't know of any background reading, but the fundamental issue is that
the delivery software (postfix, sendmail, etc.) is completely different
from the IMAP software. In order for the IMAP software to report a change
in the mailbox, it must learn about the change itself. There are two ways
in which it can do so:
1) it periodically looks to see if there is a change.
2) it is told that there is a change.
The (1) method is the easiest, and hence the most common. In the normal
"Pull" operational mode of IMAP, this happens whenever the IMAP server
executes a command. Hence the periodic use of a NOOP command in an idle
IMAP session, which by itself does nothing but does cause a check for new
mail. [Note that it is a *myth* that "NOOP is a command that checks for
new mail; *every* IMAP command does this!! So there is *no* reason to do
a NOOP if you are doing something else! A client only does a NOOP if it
has nothing else to do but wants to cycle the IMAP protocol state and
cause a new mail check.]
Alpine's default polling internal, established in the earlier 1990s, is 2
minutes and 30 seconds which at the time was a reasonable compromise
between quick response and not overloading the server. I think that
Alpine insists that this be a minimum of 15 seconds. Modern mail stores
can be checked more frequently; but I have always kept Alpine's default
and have never been particularly troubled by having to wait for 149
seconds to get my latest spam.
The (2) method requires some form of agreed mechanism between the mail
delivery software (which knows that it has added new mail) and the IMAP
server (which needs to be told). In many mail stores, including the
traditional UNIX mailbox format, there is no such agreement; the software
that wants to know about new mail must check by itself.
UW imapd's IDLE command checks at a one-minute interval. This is
hardcoded into UW imapd. It could be made smaller or larger. It's never
really mattered.
Good point, well made. However, a similar argument can be applied to HTML
email versus plain text. We all know that plain text is perfectly good, but
there's a lot of HTML emails about.
That doesn't mean that we have to like it, nor tolerate it from our family
members and other contacts who can be trained not to do it. It helps a
lot in the training process to point out that if HTML mail is disable,
it's harder to deliver malware via email or have bad guys know that you
read your email...
Most of the people that I interact with
using email (the customers of my business) use Exchange servers and
Blackberries. They use email like IM, and forget that I can't.
Blackberry isn't email. It is Blackberry messaging which properly should
be thought of as a completely different service.
As I mention in my previous message, the Internet protocol suite has IM
type services. They have not taken off and/or were deprecated as
"useless" by the UNIX world in the 1980s (much to the objection of people
in non-UNIX worlds who used those mechanisms).
IMHO, a better strategy is to persue the deployment of IM-specific
services.
I've always
had my poll interval at 5 minutes - fearing that (with everything else I'm
asking the box to do - it also for example records and processes off-air
television) 1 minute intervals would be too much.
Without knowing the details of your box, 5 minutes seems to be a bit
conservative. Given how NAT boxes act, I would probably want a faster
interval than that just to ensure that I don't lose my NAT mapping (even
though it should not matter when doing polling from the client).
If they run on the same system, why are you using IMAP? This question is
especially apt with Apple Mail, which clones the IMAP server mailbox
structure in its own private client store.
I'm using IMAP because I use more than one computer to read email, and I like
them all to be synchronised. I don't have to use the same client on every
machine, so is there a better client to use on the server machine? (I suspect
you're going to say Alpine... and I'll take a look at that.)
I don't have much good to say about Apple Mail. Apple is quite insular,
worse than Microsoft, and has never cared about playing ball with others.
However, any UNIX based mail client ought to interoperate for local mail
access with UW imapd using traditional UNIX mailbox format.
If you want to use one of the superior mailbox formats that UW imapd can
offer, then you should use a mail client based upon the UW c-client
library (such as Alpine). The same holds true for other IMAP servers
(e.g., if you use a maildir-based server such as Dovecot, it should
interoperate with a maildir-based local mail program).
I declined the opportunity to buy an iPhone - overhyped and overpriced.
I agree. I bought an iPod Touch in order to play with the iToy software
and have a test platform when people who use iToys have problems. It's a
nice media player, but underwhelming as an email platform. I certainly
would not use such a limited device as a phone.
Well, all things considered, it looks like the idea's dropped. Perhaps I'll
give 1 minute intervals a go. However, I would like to get to the bottom of
why "nothing happened" (the client never asked the server for "real" mail).
If there is some background reading that you think would help, please point
me there...
Can you be more specific? Are you saying that new mail arrived, but that
even after waiting a minute or more you never say it?
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Imap-uw mailing list
Imap-uw@u.washington.edu
https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
