You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
@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)
- 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.
Activity
jeremy commentedon Oct 11, 2018
@ZipoKing could you kindly share the original email message?
ZipoKing commentedon Oct 12, 2018
@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.1rc1jeremy commentedon Oct 13, 2018
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 commentedon Oct 13, 2018
@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:
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 commentedon Oct 15, 2018
More from https://tools.ietf.org/html/rfc2821#section-4.4:
Strange situation overall.