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

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

Am 27.03.20 um 09:08 schrieb Skle.pik:
> I did check POP3 side with Python poplib and clearly the Return-Path
> is split across lines - result below:
>
> (b'+OK',
> [b'Return-Path:
> <noreply=abba.com__al4bl7qh36xreia2@35p9h14cih4s.6f-1gv0suag.ap',
> b' 11.bnc.salesforce.com>',
> b'Delivered-To:
>
> Does anyone know who is to blame - is this Return-Path formatting
> violation on POP side, or maybe it is mailer being intolerant ? 

Looking at your Python trace and assuming it's represented properly
here, the header isn't legit (per RFC5322) because the CFWS after the
.ap at the end of the first line terminates the first atom or 1*atext
and before the next atom/atext there would have to be a dot, so you'd
need to trace back to the originator (which may or may not have been
Salesforce) where it broke, or if the originator who pretended to have
been (and may or may not have been) Salesforce sent garbage already.

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.

FTR, which fetchmail version are you using?