On Sat, Mar 10, 2001 at 01:12:13PM -0500, John R Levine wrote:
> The usual mailbox vs. maildir war has flared up on inet-access, and points
> out a bug in qmail-pop3d. When you do a LIST command, it gives you the
> size of each message. Pop3d just reports the file sizes, while it's clear
> from the RFC that it's supposed to report the wire size of each message,
> i.e., the size using cr/lf as a line terminator, so the sizes it reports
> are too small.
Yes, this is known.
> I gather nobody's ever reported this as a bug, and I expect that the only
> thing that uses the size is the "don't download bigger than size X" option
> for which it's close enough, but it's still wrong.
>
> I use courier-imap, and its POP daemon does get the sizes right,
> presumably by reading the files and adding the number of \n characters.
Yes. This behaviour is known. Fixing it, however, involves a *huge*
performance downgrade of qmail-pop3d.
I have studied the wording in RFC1939 heavily (section 11 "Message
Format" specifically) and I think it is unclear.
'Usually, during the AUTHORIZATION state of the POP3 session, the POP3
server can calculate the size of each message in octets when it opens
the maildrop. ..... simply counts each occurance of this character in
a message as two octets.'
The concept is obvious. The design decision made in qmail-pop3d
however, is understandable, and I (as one of a few users who are aware
of this 'bug') can perfectly live with it.
The only other maildir MDA+pop3 implementation that I have played with
is Cistron's. Their Maildir MDA counts the number of lines (it's
passing the message through anyway) and adds a Lines: header. The
pop3d opens each message (something qmail-pop3d doesn't have to do
right now) and reads the headers to find the Lines: line. It then uses
this to calculate the LF->CRLF overhead. This is not as expensive as
counting the number of lines from the pop3d itself, but it does take
away a lot of the performance benefit of Maildir.
Greetz, Peter.
