Multiple Return-Path headers are not being processed correctly

[ZipoKing]

1. Go to your Gmail account A@gmail.com
2. On settings page enable autoforwarding to B@example.com
3. Send some email to A@gmail.com
4. Fetch forwarded copy from B@example.com
5. When in raw email the top-one "Return-Path" header points to Gmail account from which forward action has been performed then Mail.new(raw_forwarded_email).header['return-path'] returns original one and the top one is marked as "unparsed value", which is wrong IMHO. The top one should be treated as valid.

[jeremy]

@ZipoKing could you kindly share the original email message?

[ZipoKing]

@jeremy sample test email: https://gist.github.com/ZipoKing/f6a572e092dc8dfc050e6bff2ee8f0b1
I've set autofrowarding within pawel@xap.ie account to email in devmail.onepagecrm.eu domain which is handled by Amazon SES. In this case I've sent email from zipoking@gmail.com to pawel@xap.ie which then has been forwarded by Gmail to target account. Doing Mail.new(raw_email).header['return-path'] returns original sender (zipoking@gmail.com) instead of the top one related to pawel@xap.ie. Checked both on version 2.7.0 and 2.7.1rc1

[jeremy]

Note that your MTA should be removing the earlier Return-Path header when it relays the message, leaving a single header to parse. Looks like SES is a special case, maybe? Unclear about its behavior.

Agreed that Mail should be parsing the top header when more than one is present, in any case.

[ZipoKing]

@jeremy yes I have found this as well but RFC document itself says that it is obsoleted by RFC2822 and there (https://tools.ietf.org/html/rfc2822#section-3.6.7) does not say anything that it must be only 1 Return-Path element. Moreover, Section 4.4 of RFC2821 mentioned there says:

When the delivery SMTP server makes the "final delivery" of a
message, it inserts a return-path line at the beginning of the mail
data. This use of return-path is required; mail systems MUST support
it. The return-path line preserves the information in the from the MAIL command. Here, final delivery means the message
has left the SMTP environment. Normally, this would mean it had been
delivered to the destination user or an associated mail drop, but in
some cases it may be further processed and transmitted by another
mail system.

So from what I understand there may be multiple Return-Path elements and the top one should be used as the final one. (Also AFAIR MTAs do not modify any existing email headers and just adding their own on the top of old ones)

[jeremy]

More from https://tools.ietf.org/html/rfc2821#section-4.4:

   -  a gateway from elsewhere->SMTP SHOULD delete any return-path
      header present in the message, and either copy that information to
      the SMTP envelope or combine it with information present in the
      envelope of the other transport system to construct the reverse
      path argument to the MAIL command in the SMTP envelope.

Strange situation overall.