To expand on Sam's comment slightly, the POP3 RFC requires that
the messages size (as reported by LIST) include two bytes for each
end of line marker, regardless of how the mail is stored locally.
Maildir messages (under UNIX, does anyone use Maildir under windows?)
represent the end of line with a sing byte (newline character, \n). But
the RFC wants the end of line to be counted as two bytes (I guess pertending
it's a cr-lf like in DOS).
This doesn't cause a problem for mbox based pop3 servers, since they have to
read the entire mbox anyway (so there is little overhead with counting
newlines). But Maildir pop3 servers are a different story. In order to meet
this requirement courier has to read then entire mailbox every time the user
logs in (this is done before they issue the LIST command, right at login)
with pop3.
There are ways around this, using stat() calls or parsing Maildir++ filenames,
but these do not adher to the RFC. If you're looking for someplace to start,
check our imap/pop3dserver.c .
This problem is very pronounced if you've got NFS mounted maildirs.
Sam is absolutely right, if the user needs their mail on the server, they need
to use IMAP. Hopefully I didn't say anything here that was incorrect, Sam can
beat me down if I did :)
Rock On.
On Wed, Aug 21, 2002 at 08:18:30PM -0400, Sam Varshavchik wrote:
Joel T. Osburn writes:
IDE disk. Roughly half the users have very small Maildirs, while the
other half, while having under 200 messages, have some very large
attachments so that their total /Maildir/cur is up to 20 MB. I'm trying
POP3 is not a remote mail storage protocol. POP3 is a mechanism for
downloading mail from a remote mailbox. If you want to keep your mail
remotely, that's what IMAP is for.
This was the case on the old uw-imap/mbox system, and the load was
dramatically less. Wouldn't maildirs be less load than mbox?
Not necessarily. POP3 requires that each message in the mailbox must be
read in its entirety when the mailbox is open.