On Sun, 4 Sep 2005, Olin Lathrop wrote:

> Peter wrote:
>> Also, pop servers do not look at 'line lengths'
>
> Maybe not overtly, but they often have an upper line length limit and simply
> truncate lines at that limit.  I'm pretty sure that's exactly what's
> happening.  Since there is no standard that specifies how long a line a POP3
> server must handle, the right answer is not to send long lines in the first
> place.

I have the source of three commonly used pop servers, and none of them 
does anything about line lengths, excepting in the headers, whose line 
maximum length is fixed by the RFCs (but most programs reserve liberal 
extra space for them, beyond that). Once the headers were seen the 
program just pumps data (even ignoring the Message-Length: size of so 
set up) until it sees another header. The would be header is detected by 
running a regexp match in a ring type buffer. The ring buffer itself 
grows as needed while the berkeley mail file (if used) is read in and 
indexed and usually is at least 2 times the size of the disk block size 
for efficiency at the beginning (8kbytes or much larger).

Anyway, any pop server the message would go through, would be the one 
doing the final delivery (i.e. yours in this case).

This was most likely another hidden 'feature' of that program, one that 
appears when the dead fish and the moon are on the correct side of 
Venus, and since nobody has the source we will never know what it was, 
let alone fix it. So expect it to happen again ;-)

Peter
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist