David Carter wrote:
Hi everyone,
I'm in the process of migrating from the UW IMAP and POP servers to Cyrus.
One of my fetchmail users has picked up an inconsistency in the way that the two POP servers handle the POP3 LAST command. The LAST command appears to be obsolete, but is still fetchmail's default mode of operation for leave mail on server if it available on the server...
It looks like the UW server hooks into the \Seen message state used by its companion IMAP server, while the Cyrus POP server does not. Consequently, the information presented by "LAST" has meaning across login sessions for the UW server but not for Cyrus which always responses:
C: LAST S: +OK 0
right after authentication takes place.
Is there a particular reason for the difference in behaviour? I couldn't find anything in the info-cyrus list archives.
RFC 1460 says nothing about maintaining this info across sessions. It also doesn't prohibit it. The Cyrus behavior seems perfectly reasonable and correct according to the ancient spec which defines it.
Any other suggestions? The fetchmail manual page says:
"Under POP3, blame RFC1725. That version of the POP3 protocol specification removed the LAST command, and some POP servers follow it (you can verify this by invoking fetchmail -v to the mailserver and watching the response to LAST early in the query). The fetchmail code tries to compensate by using POP3's UID feature, ...
which implies that fetchmail automatically falls back to using UIDL if LAST isn't available. Are there likely to be nasty consequences of just disabling the LAST command in pop3d.c? At the moment it looks like any POP clients which are configured to use LAST rather than UIDL will download all of the messages at each poll interval which is rather undesirable.
I'd say that your problem is with fetchmail. Since LAST is obsolete (quite possibly because of the ambiguity you have seen), fetchmail should default to using UIDL, and then fallback to LAST iff UIDL isn't available. UIDL was designed specifically to keep track of messages and SHOULD be the preferred mechanism used by clients.
-- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key-- http://www.oceana.com/~ken/ksm.pgp
