We both know exactly what causes messages to lose credentials: - A record that is only SMTP validated, which is then forwarded without SMTP rewrite - A message which is forwarded after modifications, such as the ubiquitous "this message received from an external source". Of course, it could be a mailing list modification also.
The point of an NP test was, in my understanding, to identify names that were never valid in any circumstance, like 'junk.junk.ietf.com", without any dependencies on message path. Why would we want to create a duplicate of the mailing list problem? However, if MX/A/AAAA is really the right test for fraudulent identifiers, then we need to open a CVE against all implementations of RFC7489, because implementations based on that spec have been confidently asserting honest identifiers without checking the MX/A/AAAA condition. Why do I need to provide case studies? Isn't the burden of proof on the team that told us that MX/A/AAA was absolutely the best possible test to use? On Thu, Dec 16, 2021 at 1:46 AM Murray S. Kucherawy <[email protected]> wrote: > On Wed, Dec 15, 2021 at 9:58 PM Douglas Foster < > [email protected]> wrote: > >> 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". >> > > The nearest thing I can imagine that would cause this is a From of " > [email protected]" when that domain advertises a public key that verifies > the message, so it has a TXT at "selector._domainkey.example.com", but > has no MX, A, or AAAA for "example.com". On relay, a mutation causes the > signature validation to fail at the final recipient. > > Are you seeing cases like this? > > -MSK > >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
