7 messages in net.sourceforge.lists.courier-usersRe: [courier-users] Re: Slow pop3d
FromSent OnAttachments
Joel T. OsburnAug 21, 2002 3:06 pm 
Peter C. NortonAug 21, 2002 3:25 pm 
Joel T. OsburnAug 21, 2002 4:25 pm 
Sam VarshavchikAug 21, 2002 5:18 pm 
Joshua E WarcholAug 22, 2002 5:53 am 
Joel T. OsburnAug 22, 2002 7:54 am 
Peter C. NortonAug 22, 2002 9:05 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: [courier-users] Re: Slow pop3dActions...
From:Joshua E Warchol (jwar@dsl.net)
Date:Aug 22, 2002 5:53:43 am
List:net.sourceforge.lists.courier-users

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.