On Wed, Apr 21, 2004 at 11:29:57PM -0700, Roger Ivie wrote:
It appears that Maillenium treats any TOP command that specifies more
than 2242 lines to be equivalent to TOP x 2242; consequently, messages
longer than about 80KB get truncated.
The workaround I'm using is to set fetchall in my .fetchmailrc to cause
fetchmail to use RETR instead of TOP.
...
I'm at a loss to explain the number 2242, since it does not appear to be
a "magic" number (i.e., an even power of two or near one).
My first reaction to this was "buggy POP3 server", since RFC1939 doesn't
permit the server to arbitarily truncate the message. However on a bit more
investigation, I'm inclined to say that it's a poor design decision in
fetchmail which is triggering this.
Fetchmail by default uses "TOP n 99999999" instead of the obvious "RETR n"
to fetch an entire message. I disagree with the comments in the source as to
why this should be done - in my opinion, it should not. Maybe 10 years ago
it might have meant something, but everyone uses UIDL rather than LAST these
days (and in any case, if a POP3 session is terminated prematurely, the POP3
server is not supposed to update mailbox state)
I thought there might be some integer wrapping going on, although 99999999
wrapped to 16 bits is 57599 or -7937, neither of which resembles 2242, so
I'm not sure exactly why or how your POP3 server is mangling this value.
Regards,
Brian.