Re: [Fetchmail-users] (jmm) Fetchmail failed to fetch

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

Am 22.10.20 um 19:56 schrieb James Moe via Fetchmail-users:
> On 10/22/20 10:28 AM, James Moe via Fetchmail-users wrote:
>
>>   Fetchmail had trouble with this one message. Both fetchmail and the local mail
>> server blamed each other for the failure.
>>   The message is a trojan with a tainted XLS file; about 126KB.
>>
>   Well. I got that one way wrong. I forgot about the Spam proxy between
> fetchmail and the server.
>   I updated the log file with the proxy's log. It makes sense that the mail
> server logged a broken connection, because that is what happened: the proxy
> flagged the mail as spam and dropped the connection.
>   However, the proxy also returned a 554 message to fetchmail that was ignored,
> repeatedly.
>   The first log section of the proxy is normal. The following two are the proxy
> wondering was is wrong with fetchmail.

well, the connection appears to be broken by the proxy before the 554
can be properly received. T

here's some equivocation in the error path, so the information of what
exactly failed isn't available in the place that traps and reports the
error.

There's also not much debugging either that could be enabled, but you
might be able to use truss, strace or ktrace on fetchmail to figure what
fetchmail did and which syscall broke.

To me, it looks as though a socket send or pipe write to an MDA failed
from the proxy breaking the connection, and even if the proxy attempted
to write the 554 before fetchmail has completed sending the body, if the
proxy then jams the connection, that 554 may not arrive because
fetchmail receives the TCP RST packet before having sent all of its
data, the next write fails due to the closed socket or broken pipe, and
in that situation, fetchmail itself also breaks the connection.
Fetchmail will only try to read an error code after sending the SMTP
"DATA" and the CRLF.CRLF completely, because well-behaved servers will
not reply sooner.