[courier-users] Re: Weird problem(?)

[Robert L M. <li...@ti...>]

At 1/4/02 8:53 AM, Sam Varshavchik wrote:

>Morten Wartou writes: 
>
>> ----- Original Message ----- 
>> From: "Sam Varshavchik" <mr...@co...>
>> To: <cou...@li...>
>> Sent: Friday, January 04, 2002 12:31 AM
>> Subject: [courier-users] Re: Weird problem(?) 
>> 
>> 
>>> >> Morten Wartou writes:
>>> >> > We have just discovered that the Courier POP3 daemon reads through 
each
>>> > emailfile even though we use the Maildir-format. Is this the intention? 
Is
>>> > there any way we can get around it?
>>> >> This is required in order to fully comply with the POP3 protocol, which
>>> >> calculates message sizes using CRLF newline terminators.
>>> > Oh... Heck. :) Do you know how is this messagesize returned to the 
client?
>>> In STAT/RETR commands, I believe. 
>> Stat and retr, and list by the way, returns the size in bytes.
>
>... With CRLF being the line terminator. 
>
>> I cannot find any POP3 command that needs the number of lines in the mail. 
It 
>seems as a complete waste of time and I/O-capacity.
>
>Here's a file.  Go ahead, use stat(), and try to calculate the size of the 
>message with an extra CR tacked on at the end of each line.

Once this information is calculated, is it cached anywhere so that the 
next mailbox access can use it without re-reading the file?

I'm imagining a situation where someone likes to leave messages on the 
server, and they have several hundred on there, almost all of which have 
been previously read. When that person connects and does a STAT, does 
Courier have to re-read each message to calculate this information, or 
does it only have to calculate the size of the new messages?

If it's re-reading each message, it would seem a dramatic speed 
improvement could be obtained by caching the size for later use, perhaps 
by renaming the file, while still remaining RFC 1939-compliant. I know 
that Maildir++ stores the size of the message in the name as 
"xxxx,S=nnnnn", but it unfortunately stores the size as reported by 
stat(), and not the CRLF octet size.

--
Robert L Mathews, Tiger Technologies