To be clear, we don't evaluate based on the Return-Path header, we evaluate based on the MAIL FROM argument, which we use to populate the Return-Path header... I don't think we usually read any return-path headers ... though I can't speak for the entire anti-spam engine, I guess.
Brandon On Thu, Apr 11, 2019 at 3:34 PM Autumn Tyr-Salvia <[email protected]> wrote: > Hello, > > Thanks everyone for your comments on this! What I think is happening is > that the ESP is inappropriately inserting an additional Return-Path header > using the same address as in the friendly From:, while the receiver (in > this case, my Gmail test account) is inserting the correct Return-Path > header that preserves the SMTP MAIL FROM, which is the VERP address using > the ESP's domain. In turn, Gmail is evaluating SPF with the Return-Path > header using the ESP domain, which passes baseline SPF but is not aligned > and thus does not pass DMARC-SPF. > > I'm looking into this to help evaluate why a particular announcement > didn't get the level of performance they expected, and trying to see if > there's anything we can optimize in the headers before having them look > into content and list (both of which seem reasonable in theory, but the > devil is always in the details). I doubt having two Return-Path headers is > causing delivery performance issues, but we do want these messages to pass > DMARC-SPF, and it's kind of confusing with two headers where one is aligned > and the other isn't. At the end of the day, I think I can say that these > headers are not aligned and the ESP is just doing something weird with that > second header. > > Thanks, > > Autumn Tyr-Salvia > tyrsalvia@gmail > atyrsalvia@agari > > On Thu, Apr 11, 2019 at 1:22 PM Bill Cole < > [email protected]> wrote: > >> On 11 Apr 2019, at 15:01, Autumn Tyr-Salvia wrote: >> >> > 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? >> >> Not in non-spam. Not even in non-spam bulk mail. It is a symptom of >> immature/amatuer list exploder software. >> >> > Why would >> > there be 2? >> >> A message is sent via SMTP to a mailing list system. It is delivered to >> a mailbox by a terminal MTA which does the right thing in delivery and >> adds a Return-Path header with the SMTP envelope sender address in it. >> The list exploder software picks up that message for resending and sends >> it out with a unique VERP envelope sender for each recipient, neglecting >> to strip the existing Return-Path. Terminal MTAs doing final delivery >> MAY (but generally do not) strip existing Return-Path headers when doing >> their own final delivery, at which time they add their own Return-Path >> header containing the VERP address. >> >> Responsibility for stripping out the original Return-Path belongs to the >> entity that resends a delivered message via SMTP with a new envelope >> sender. >> >> > 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. >> >> In both RFC2822 and RFC5322: >> >> 3.6.7. Trace Fields >> >> The trace fields are a group of header fields consisting of an >> optional "Return-Path:" field, and one or more "Received:" fields. >> >> Note that it does not say "one or more" about Return-Path. >> >> Section 4.4 of both RFC5321 & RFC2821 discuss the meaning of >> Return-Path, wherein the key text is: >> >> [...] 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. >> >> [...] >> >> 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. >> >> >> > More to the >> > point, it's using the one with the ESP domain for checking SPF, which >> > is >> > not what the desired behavior. >> >> I'm not able to parse out an identity for your use of "it" here... >> >> SPF applies to the envelope sender in an SMTP transaction, not to ANY >> header, however it could in theory be used post-delivery on a >> well-formed message, applying to the ONE Return-Path header that such a >> message will have. >> >> Anything checking SPF before final delivery should ONLY be using the >> SMTP sender address, which I expect in this case would be the VERP >> address. >> >> > 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. >> >> Multiple Return-Path headers is bad and wrong. It both causes confusion >> and violates the language of the specification of message format in the >> 2 latest revisions of that spec. >> >> >> -- >> Bill Cole >> [email protected] or [email protected] >> (AKA @grumpybozo and many *@billmail.scconsult.com addresses) >> Available For Hire: https://linkedin.com/in/billcole >> >> _______________________________________________ >> mailop mailing list >> [email protected] >> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >> > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop >
_______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
