Yes, this is important stuff. This is one of my problem scenarios:
A record arrives at the first hop and obtains DMARC PASS, based on SPF and/or DKIM interpreted by a DMARC policy. Based on DMARC PASS, the RFC5322.From address is confidently judged to be "Honestly identified" DMARC checks SPF and DKIM, but not MX or A/AAAA. But then it is forwarded and loses its credentials during forwarding. On reception, because of DMARC FAIL, it is tested against NP. NP checks MX and A/AAAA but does not check SPF or DKIM. The message fails this test and is confidently judged to be "Fraudulently identified". Which is true? Was the message From address always fraudulent or always honest? To produce consistent results, do we change DMARC to require messages to evaluate MX/A/AAAA or do we change NP to integrate SPF and DKIM? Doug On Wed, Dec 15, 2021 at 6:50 PM Scott Kitterman <skl...@kitterman.com> wrote: > On Wednesday, December 15, 2021 5:44:46 PM EST Barry Leiba wrote: > > > Scott, I have many problems with your response. Was it intended as > an > > > ad hominem? It certainly came across that way. > > > > It doesn't seem even remotely so to me. Please be careful with > > attributing intent. No one tried to say that we shouldn't listen to > > you. > > > > > If the NP objective can be stated in a sentence or two, you should have > > > done so, instead of telling me to read years of archive. An objective > > > that cannot be explained tersely is not sufficiently defined. > > > > It *is* reasonable to expect you to review earlier discussions, rather > > than to ask the working group to revisit them without a sense of how > > you're adding new information. > > Thanks. Yes, that was my intent. > > To give a short summary, in the interests of moving forward: > > The domain owner publishing the DMARC record knows and controls what > exists > and what doesn't. They don't have to guess. The question was, > particularly > in the context of PSD, but not exclusively, would record publishers find > it > useful to be able to publish a different (and presumably more strict) > policy > for non-existent domains. More p=reject equals more bad stuff not getting > delivered. > > I think we can say it's an pretty unqualified yes in the PSD realm: > > $ dig +short txt _dmarc.gov > "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto: > dotgov_dm...@cisa.dhs.gov" > > $ dig +short txt _dmarc.mil > "v=DMARC1; p=reject; sp=none; np=reject; rua=mailto:dmarc_repo...@mail.mil > " > > $ dig +short txt _dmarc.gov.uk > "v=DMARC1;p=reject;sp=none;np=reject;adkim=s;aspf=s;fo=1;rua=mailto:dmarc- > r...@dmarc.service.gov.uk" > > $ dig +short txt _dmarc.police.uk > "v=DMARC1;p=none;sp=none;adkim=s;aspf=s;fo=1;rua=mailto:dmarc- > r...@dmarc.service.gov.uk;ruf=mailto:dmarc-...@dmarc.service.gov.uk"; > > All of the current PSDs that have published records with any policy other > than > none have different sp= and np= policies. > > Scott K > > > _______________________________________________ > 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
