[fetchmail]comcast.net and attachments - workaround
Matthias Andree
matthias.andree@gmx.de
Tue, 03 Jan 2006 16:43:28 +0100
Rob MacGregor <rob.macgregor@gmail.com> writes:
> [ Note that the ccil.org lists will be discontinued in the near
> future. Please subscribe instead to the lists at
> http://fetchmail.berlios.de/ ]
>
> On 03/01/06, Ed Wilts <ewilts@ewilts.org> wrote:
>> FAQ # I8 says:
>>
>> "Stock fetchmail will work with a comcast.net server...but they seem to
>> have an 80K limit on the length of downloaded messages. Anything larger
>> is silently truncated. Don't mistake this for a fetchmail bug."
>>
>> I have found a workaround to this issue that may work for some people -
>> it works for me. I added fetchall to my .fetchmailrc and this works
>> around the problem. Interactively, fetchmail -a also works.
> <---SNIP--->
>> [ewilts@pe400 ~]$ fetchmail -V
>> This is fetchmail release 6.2.5+IMAP-GSS+RPA+NTLM+SDPS+SSL+INET6+NLS
>> Fallback MDA: (none)
>> Linux pe400.ewilts.home 2.6.9-22.0.1.EL #1 Thu Oct 27 13:20:09 EDT 2005
>> i686 i686 i386 GNU/Linux
>
> It would be good to know the state of affairs with 6.3.1 (the current release).
Don't waste time checking, I didn't make those major changes before 6.3.X
to get rid of all the server-side "seen" tracking junk that ESR insisted
on. First and foremost, we needed a migration path that was as
compatible as possible, and apparently, 6.3.X has achieved that goal.
"Jakob Hirsch" <jh@plonk.de> writes:
> The reason for that is that fetchmail uses TOP by default (stupid, IMHO,
> but ESR insisted on this for some kind of poor man's IMAP), but RETR when
> fetchall is set. And as the FAQ says:
>
> Stock fetchmail will work with a comcast.net server...but the Maillennium
> POP3 server comcat uses seems to have an 80K limit on the length of
> downloaded messages if you use POP3 TOP to retrieve. [...]
fetchmail will gradually move to client-side seen tracking since that's
the only reliable way to do it, and we'll probably get rid of TOP
because it's just too painful with the many b0rked upstreams.
In the meanwhile, please complain to comcast.net for violating the POP3
standard, which states expressis verbis that the full message is to be
fetched if the number passed to TOP exceeds the actual number of lines
in the message.
--
Matthias Andree