On Tue, Jun 01, 2004 at 12:06:49AM +0200, Matthias Andree wrote:
I don't believe they have any permission to assume this. If the server happens to maintain this ordering, well, the client could attempt some sort of dubious binary-chop to work out where new mail has arrived (since some or all messages may have been deleted)
Yup, given the lack of a range for UIDL, this is necessary.
I wouldn't say "necessary" - I'd say "a possible optimisation not sanctioned by the RFC"
But anyway, I'm sure you'd agree that clients are not *required* to perform this optimisation. So, some (many?) clients do ask for a complete UIDL listing every time they connect. If there are 1000 old messages in the mailbox, then you definitely don't want to open and read every one to find its X-POP3-UID header. Equally, clients may ask for a complete LIST of the maildrop. Again, you don't want to open and read every message file just to calculate its size.
courier-imap used to do this, and the load was enormous from clients which left mail on the server. Once it introduced a cache file (courierpop3dsizelist), this problem went away. (This file also stores the UID; previously it had used the Maildir filename as UID, but this turned out to be too long for some clients)
I'm not trying to be pro-courier-imap here, by the way. I'd be happy to have a path to bail out; but there are some key features that I need to have first. One is Maildir++ quotas, and another is efficient POP3 operation in the presence of clients who leave mail on server, and issue a full maildrop UIDL and/or LIST each time they connect. A mechanism for transparent migration of mailbox contents from a remote POP3 server is another. If I can preserve the original UID of each message when migrating mail, then this will be a bonus which courier-imap doesn't give me.
Oh, and perhaps most important of all, I need robustness. The pop3/imap server should not die and drop the connection, say because a message within the maildrop is mailformed in some way.
Regards,
Brian.