Re: [Fetchmail-users] Weird Return-Path processing

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

>> However you seem to be proving that fetchmail is not unfolding the line
>> properly, and is shipping out this broken line via SMTP (RFC5321), which
>> isn't permitted either, the SMTP Domain can't have blanks or line
>> breaks, so this seems to be a bug. Given that RFC5322 Return-Path:
>> header syntax is more permissive than RFC5321 SMTP MAIL FROM:<...>
>> syntax, fetchmail needs to validate input and act accordingly.
> Ok, so what would be fetchmail action then ? Skipping pushing message
> based on malformed field detection ?

Good question. The simplest reaction would be "leave message on server"
and tell local user about it.
It might also wrap the message in an attachment and replace the return
path, or somehow sanitize the return path, but traditionally we haven't
enforced that fetchmail is configured with a reply-capable sender address.

>>
>> FTR, which fetchmail version are you using?c
> It is 6.3.26 but I checked several 6.3.x versions and they all handle
> this case in similar way (except maybe from really old 6.3.8 which did
> removed the message from the server despite SMTP failing).

6.3.26 is also in the "really old" and "no longer supported" categories,
but 6.4.2 doesn't help in this particular case I think, but you'll
likely need to upgrade soon as providers are going to tighten up their
TLS support levels, and then you'll be out of luck with 6.3.x. See
https://gitlab.com/fetchmail/fetchmail/-/blob/legacy_64/NEWS#L68 for
6.4.2 all the way back to 6.4.0 changes.