Jeff Sutherland wrote:
Several weeks ago the munkis at AT&T Worldnet began some kind of email
"upgrade" that they're still recovering from. Fetchmail is no longer able to
pop off messages with attachments larger than around 300K from their secure
pop server. Regardless of size, messages get truncated to about 81K. The
server reports the correct message size, but then fetchmail always aborts
around 81K, looks like it got an EOM for some reason.
Could be related to the problems I saw at comcast.net. Here's how I
solved my problem last July:
With the recent move of some POP3 services from attbi.com to comcast.net,
I started to notice truncation of messages at just under 80 KB for email
accounts hosted at comcast. I ran a bunch of experiments before/after
finding a FAQ item about the problem:
http://catb.org/~esr/fetchmail/fetchmail-FAQ.html#I8
The problem appears to be caused by a bug/limitation in Comcast's
Maillennium POP3/PROXY server implementation of the TOP command
and not an overall limitation on message size like the FAQ implies.
POP3 clients such as MS OE 6.0 see no message truncation because they
use RETR instead of TOP.
Adding the "fetchall" keyword to the fetchmailrc entries for comcast.net
servers solves the problem by forcing fetchmail to use RETR instead
of TOP:
Bad:
poll mail.comcast.net proto pop3
user "me" pass "secret" is "me" here
Good:
poll mail.comcast.net proto pop3
user "me" pass "secret" is "me" here fetchall
This should be added to the FAQ as an acceptable work-around.
Seth