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

[Matthias A. <mat...@gm...>]

Frederic Marchal <fre...@wo...> writes:

> 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 ?

Finding out if it's in Mercury/32 or Wingate or outside both.

> 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.

Which is assuming that it's looking at a body line rather than a header,
on the assumption that all header lines either start with whitespace, or
with a sequence of non-space characters terminated with a colon (":").

I'm not sure if it's still needed, and the segfault had probably better
be fixed in the place where it actually occurs, but that's stuff for
6.4.0, I'm not going to attempt removing this workaround in 6.3.X to
avoid user astonishment.

-- 
Matthias Andree