(Subject ticket number corrected.) Michael, I am surprised and disappointed by the severity of your critique.
NP Policy ------------- The NP policy is upon us. PSD for DMARC demonstrated the need. The problem is that their definition of NP, which the current DMARCbis draft inherits, is a pre-SPF test for an invalid SMTP MailFrom address. It is a bizarre stretch to apply that test to the RFC5322.From address. The current test is insufficiently defined, undefended, and indefensible. It must be fixed. The focus of this draft is a proposed fix, because there have been no other fixes offered. The key insight behind the NP policy idea is that some domain abuse can be detected and rejected without depending on the attributes which create the mailing list problem. The best boundary for the NP policy is between those names that are used as FROM address and those that are not. Domain owners currently lack sufficient mechanism to signal that condition correctly. I evaluated options based on NXDOMAIN, but rejected them. Even when done perfectly, NXDOMAIN excludes a smaller set of unauthorized names than this approach, and seems more difficult to implement. NXDOMAIN has some nuances which I found problematic. This proposal introduces relatively low compliance measures for those domain owners that wish to implement NP. The Introduction ---------------------- As to the introduction, I think the relationship between SP=NONE and the mailing list problem has been well elucidated. Nor do I think that an introductory sentence needs to enumerate all possible reasons for SP=NONE. But if you prefer to simply say "some domain owners have difficulty moving beyond SP=NONE,", without any additional comment, I can accept a change along those lines. Getting the correct definition of NP is my priority, not the opening sentence. Validate vs Reject ------------------------ Sender authentication involves two partially independent goals: proving that a message is definitely authorized, and proving that a message is definitely not authenticated. Proving authorization is only relevant for names that are used as email addresses. Proving non-authorization has a much larger scope, because it involves all possible names, not merely in-use names. RFC 7489 attempted to prove non-authentication based on domains achieving SP=REJECT and messages being delivered without in-transit loss of credentials. This has not worked out well in practice. NP defines non-authentication based on attributes which are not dependent on transit, and therefore it is a very powerful idea. Level of Detail ------------------- I could be convinced to move some of this content into a Best Practices document., But my target audience is not limited to the big organizations that can build custom code and spend a large amount of money on consultants. I am equally concerned about the smaller players who are dependent on off-the-shelf products available from vendors, and the developers witin those vendors who often implement to the specification rather than to the security problem. So yes, I favor laying things out clearly, rather than assuming that sophisticated people will be able to read between the lines. If you have a different definition of NP, let's hear the proposal and its defense. Doug Foster > >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
