Re: [fetchmail-devel] Re: [fetchmail-users] Incorrect header line and lost mails

[Frederic M. <fre...@wo...>]

Matthias Andree wrote:
> Frederic Marchal <fre...@wo...> writes:
>
>   
>> I expect this mail will be wrapped so here is the explanation. The
>> References header is one long line and is wrapped at some point after
>> the <43ea8d070602140508w6af9d34aq5c which leaves the
>> 222...@ma...> all by itself on a line. You have
>> received that e-mail and can compare it to your copy
>>
>> On my side, the References line is truncated at column 263. rfc821
>> specifies a maximum line length of 1000 characters but an implementation
>> should be prepared for longer lines or reject the mail. It is not what
>> is happening here.
>>
>> The culprit may be Mercury/32 or the Wingate proxy which is not listed
>> in the header.
>>     
>
> Is there any chance we might isolate the bug before we fix it? 
>   
Isolate in what ? Mercury or fetchmail ?

I installed a Mercury/32 server on my computer and I made some tests. 
The header remains intact until it is fetched from the POP3 server by 
the client. This bug is not (yet) mentioned on the mailing list of the 
project. It is a closed source project and there seems to be only one 
very busy developer. I won't get any help from there.

In fetchmail, the problem is clearly located in transact.c (I wouldn't 
call it a bug until I get some clarification from the one who wrote it). 
The part of the code that rejects the mail is preceded by a comment stating

         * At least one brain-dead website (netmind.com) is known to
         * send out robotmail that's missing the RFC822 delimiter blank
         * line before the body! Without this check fetchmail segfaults.
         * With it, we treat such messages as spam and refuse them.

But the test after this comment doesn't test for the beginning of the 
body but for a header line not starting with a blank and not containing 
a colon. If the condition is true, refuse_mail is set to 1 and the 
function returns PS_REFUSED which delete the mail on the server.

Frederic