On Saturday 29 November 2003 16:07, Seth Zirin wrote:
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
Indeed it should be, for it FIXED my problem with AT&T Worldnet! Thanks,
Seth, for posting this. Hopefully the FAQ maintainer(s) will pick up on
this.
Regards,
-Jeff
--
Kodachrome: After nearly 70 years, there's still
no better way to preserve an image.