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

[Ralph C. <ra...@in...>]

Hi Skle.pik,

> Here is plaintext version of a message with some updates:

Thanks, unfortunately it has wrapped the lines, but we can undo that.

> The investigation of processing for not delivered mails shows
> Return-Path to be split to 2 lines:
> Return-Path: 
> <noreply=abba.com__al4bl7qh36xreia2@35p9h14cih4s.6f-1gv0suag.ap
> 11.bnc.salesforce.com>
> Delivered-To:

Unwrapped:

    Return-Path: <noreply=abba.com__al4bl7qh36xreia2@35p9h14cih4s.6f-1gv0suag.ap
    11.bnc.salesforce.com>
    Delivered-To:

> Unfortunately this makes mailer choking:
> SMTP> MAIL 
> FROM:<noreply=abba.com__al4bl7qh36xreia2@35p9h14cih4s.6f-1gv0suag.ap
> 11.bnc.salesforce.com> SIZE=4070
> SMTP< 553 5.0.0 ....

Unwrapped:

    SMTP> MAIL FROM:<noreply=abba.com__al4bl7qh36xreia2@35p9h14cih4s.6f-1gv0suag.ap
    11.bnc.salesforce.com> SIZE=4070
    SMTP< 553 5.0.0 ....

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

The POP3 server is dishing up the split line as you have used to
separate POP3 clients and both show the problem.

The number of bytes in

    $ wc -c
    MAIL FROM:<noreply=abba.com__al4bl7qh36xreia2@35p9h14cih4s.6f-1gv0suag.ap
    ^D
    74
    $

is 74, including the linefeed, and that's a typical length for folding
text, though obviously it shouldn't be doing it to protocol lines.

-- 
Cheers, Ralph.