According to current practices and standards, Return-Path header should never be added by sender. This line is usually added by MDA (Mail Delivery Agent) when the message is delivered to mailbox and is always a first line of delivered message, but older systems could add Return-Path during transfer. You can safely ignore any Return-Path which is not a first line in the message delivered to mailbox. See https://tools.ietf.org/html/rfc5321#section-4.4 it's very clear on this:
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 <reverse- path> 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. It is possible for the mailbox in the return path to be different from the actual sender's mailbox, for example, if error responses are to be delivered to a special error handling mailbox rather than to the message sender. When mailing lists are involved, this arrangement is common and useful as a means of directing errors to the list maintainer rather than the message originator. The text above implies that the final mail data will begin with a return path line, followed by one or more time stamp lines. These lines will be followed by the rest of the mail data: first the balance of the mail header section and then the body (RFC 5322 <https://tools.ietf.org/html/rfc5322> [4 <https://tools.ietf.org/html/rfc5321#ref-4>]). It is sometimes difficult for an SMTP server to determine whether or not it is making final delivery since forwarding or other operations may occur after the message is accepted for delivery. Consequently, any further (forwarding, gateway, or relay) systems MAY remove the return path and rebuild the MAIL command as needed to ensure that exactly one such line appears in a delivered message. A message-originating SMTP system SHOULD NOT send a message that already contains a Return-path header field. SMTP servers performing a relay function MUST NOT inspect the message data, and especially not to the extent needed to determine if Return-path header fields are present. SMTP servers making final delivery MAY remove Return- path header fields before adding their own. The primary purpose of the Return-path is to designate the address to which messages indicating non-delivery or other mail system failures are to be sent. For this to be unambiguous, exactly one return path SHOULD be present when the message is delivered. Systems using RFC <https://tools.ietf.org/html/rfc822> 822 <https://tools.ietf.org/html/rfc822> syntax with non-SMTP transports SHOULD designate an unambiguous address, associated with the transport envelope, to which error reports (e.g., non-delivery messages) should be sent. 11.04.2019 22:01, Autumn Tyr-Salvia пишет: > Hello, > > I'm looking at headers for a particular message, and noticed two > different Return-Path headers. The message is being sent by an ESP. > One Return-Path uses a VERP address with the ESP's domain, and the > other uses the same address as the friendly From:. > > I haven't seen this in other headers before - is this common? Why > would there be 2? I spent some quality time with RFC 2822 and couldn't > determine if it's spec-legal to have two Return-Path headers or not. > More to the point, it's using the one with the ESP domain for checking > SPF, which is not what the desired behavior. > > I can reach out directly to the ESP in question to get more info, but > wanted to ask this group first if there's some other resource I should > consult for a firm understanding of using multiple Return-Path headers > before I have that conversation. > > > Thanks, > > Autumn Tyr-Salvia > tyrsalvia@gmail > atyrsalvia@agari > > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop -- Vladimir Dubrovin @Mail.Ru
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
