At 8:51 AM -0400 3/11/08, Andy Dills wrote:

We recently switched to atmail, as well as dovecot. I noticed in atmail the size of the mailboxes was always reported as 0kb.

So, I did some debugging, and it boiled down to the fact that the regular expression used by dovecot expected UID before SIZE,

I assume you meant to say 'atmail' there and not 'dovecot'

but Dovecot returned SIZE before UID. No biggy, I changed the regex, but I was curious if there was a standard.

Yes, IMAP4[rev1] is an explicitly defined protocol, not a mix of specification and traditions (for a contrast, see NNTP.) The versioning is a bit weird, but all 3 RFC's specifying IMAP4 and IMAP4rev1 published in 1994, 1996, and 2003 agree on this issue. This is a goofy piece of the IMAP4 spec, but it isn't really unclear and even someone coding to the examples in the RFC's would not make the error you are seeing in atmail.

RFC3501, like RFC2060 and RFC1730 before it, does not specify any ordering to the parts of a FETCH response type, and the example of a response given for a UID FETCH command in both RFC's has the UID as the last field. RFC3501 also points implementors to RFC2683, in which section 3.4.4 explicitly warns client authors to not rely on any particular order or structure in a FETCH response more restrictive than the specification, and points out just how variable a FETCH response can be. Any IMAP software that depends on an IMAP server answering with fields in a particular order would seem to be written by someone who had not bothered with a serious reading of the specifications of the protocol or looked at the implementation hints/warnings pointed to by the full specification.

Here's the imap query that is sent: UID FETCH 1:* (RFC822.SIZE)

Here's the diff I implemented to make it work: http://www.xecu.net/atmail/dovecot_sizes.diff

So...is this something that is standard or something atmail needs to handle by making their regex more dynamic?

As Timo pointed out, a regular expression is a poor choice for parsing an IMAP FETCH response to a UID FETCH command. I'm not sure that it is formally impossible for all RE flavors and certainly not for that specific UID FETCH command, but the style used in the code you have patched, with hard-coded field names, is extremely unwise. The FETCH response format is rigorously defined and is parseable, but the right approach would be to decompose the response structurally into name/value pairs rather than look for specific names in a particular order.

-- Bill Cole bill@scconsult.com