Off hand, based on what you stated, when dealing with bounces, its a general rule of thumb that you always accept and maybe then do some AVS filtering perhaps. If you want to apply SPF, fine, but beyond that, well, its going to be indeterminate conditions. You can't assume that bounces will be signed and/or it will be perfectly aligned and correct all the time. Too variable. Our receiver will pretty much always accept a bounce out of "standard" practice. It's an unfortunate loophole for support of legacy operations. Since you had using a host, you really can't put too much constraints. The host isn't a resigner. If you can't setup a hard fail policy, its all going to be wasteful and redundant processing anyway.
-- Hector Santos http://www.santronics.com > On Apr 30, 2015, at 9:37 AM, John Mears <john_me...@symantec.com> wrote: > > Hi. > > I wonder if people on this list can help me with a question about correct > behavior of DMARC and SPF in a situation involving an email with a null > sender. This reflects a real life situation where an email is being discarded > by the recipient, even though it is a valid email and I believe the DMARC and > SPF implementations are correct. > > The situation is this. There three parties involved : a sender organization; > a third party organization that provides AV services and the like in the form > of an SMTP relay; and a recipient organization. The sender organization > relays all its outbound email via the third party. > > The sender organization publishes a DMARC record p=reject and an SPF record. > The SPF record correctly includes the IP used by the third party to deliver > emails on their behalf. > > The sender does not do DKIM signing, as they don't have that capability at > present for practical reasons. Therefore, they are relying purely on SPF to > pass DMARC. > > 1 A null sender email is generated by a the sender organization. It could be > an NDR, an Out Of Office, or similar. > 2 The sender organization relays the email via the third party SMTP relay. > 3 The third party relay delivers that email to its recipient. > > The problem is that SPF checking at the recipient is based on the ehlo domain > presented by the third party relay, as the envelope sender is null. SPF > passes, but the authenticated identifier that results corresponds to the > third party, not the sender. That identifier fails to align with the from > header domain, so DMARC fails. As I said, the sender isn't doing DKIM signing > so DMARC is based purely on the SPF result. > > My feeling is that the SPF and DMARC processing I describe is actually > correct, and that this is an edge case that arises because the sender is > replying only on SPF. I'd appreciate it if this mailing list can confirm that > for me. > > Thanks > John > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
