Re: [MORG] New draft at MORG: POP3 LIST+ Extension

[Timo Sirainen <[e-mail]>]

> POP3 clients using the LIST command, and,
>    immediately followed, the UIDL command to get the Message Number,
>    Message Size and Unique-ID, of all messages of a mailbox, to see if
>    new messages have arrived.  On large mailboxes, holding hundreds or
>    thousands of mails, this causes serious resource consumption on the
>    server, and will prolong the duration a mailbox is hold in locked
>    state.  This situation is even stressed by the fact that POP3 clients
>    will usually poll a mailbox for new messages periodically in short
>    intervals.

I agree with the above, but

> Using the LIST+ Extension, a server has to scan through the mailbox
>    only for a single time, and can send the Message Number, Message Size
>    and Unique-ID in a more compact form to the client (as shown in
>    Appendix A.2.1).

I don't see this helping all that much with the server's resource
consumption or even much with the client's bandwidth consumption. The
server still has to look up all the sizes and UIDLs. In Appendix A the
client downloads 22% less.

Most of the time POP3 clients just poll an unchanged mailbox. It would
be possible to get a much more dramatic bandwidth improvement by being
able to tell clients that nothing had changed since the last time.
Here's an example of how it could work:

Client connecting for the first time:

   C: LIST +UIDL
   S: +OK 14758f1afd44c09b7992073ccf00b43d 3 messages, listing follows:
   S: 1 4536 7abcb6f4da22080e121f2824aef2be9a
   S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7
   S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e
   S: .

Client connecting the second time when there are no changes:

   C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d
   S: +OK 14758f1afd44c09b7992073ccf00b43d No changes
   S: .

Client connecting the 3rd time when there are changes:

   C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d
   S: +OK ddd2cae8a4a5ec890737d07adb537b99 4 messages, listing follows:
   S: 1 4536 7abcb6f4da22080e121f2824aef2be9a
   S: 2 4422 577151e65ea4e62bb9b1c5830a818fe7
   S: 3 3828 2fe542ac6d1c29bb6a5161558f527e2e
   S: 4 3284 86519edbbe78d203c5c9618df50b21a7
   S: .

So, the client would just remember the value after the "OK". The server
can use whatever value it wants there, but one simple possibility would
be to just use a hash(all UIDLs).

This could be made to save more bandwidth by allowing server to send
only changes based on the given ID, such as:

   C: LIST +UIDL +ID=14758f1afd44c09b7992073ccf00b43d
   S: +OK ddd2cae8a4a5ec890737d07adb537b99 1 new message:
   S: 4 3284 86519edbbe78d203c5c9618df50b21a7
   S: .

Deleted messages could also be reported by adding more complexity.

> The +UNREAD Flag requests to add the number of whole days, since the
>    message was read for last time, to the extended scan listing.

What exactly is the "last read time" for a message? RETR time? When it
was marked as \Seen in webmail/IMAP?