Thanks for pointing this out Scott, I've been sidetracked. Section 8 gives me issues also. Many of these topics I've always felt would go into a BCP on operation practices.
I am not well ensconced in the Mail community, but are this disagreements between vendors, software, etc over if one is "implementing DMARC"? On Thu, Sep 9, 2021 at 11:56 PM Scott Kitterman <[email protected]> wrote: > On Tuesday, September 7, 2021 3:16:18 PM EDT Todd Herr wrote: > > Greetings. > > > > Previous discussion of this issue a couple of weeks ago seemed to land on > > the idea that the text in Section 8 of the current rev of the draft, > titled > > "Minimum Implementations", was problematic in its content and there was a > > suggestion that perhaps the text could be softened and moved to a summary > > section. > > > > I'm writing today to seek guidance from the working group as to what > such a > > summary section might be. > > > > At first blush, it might seem that the current Section 9, "Other Topics", > > might be a place for a summary discussion of "Minimum Implementations"; > > however, the introductory text for Section 9 currently reads "This > section > > discusses some topics regarding choices made in the development of DMARC, > > largely to commit the history to record." and so "Minimum > Implementations" > > might not fit. > > > > Another choice might be to leave "Minimum Implementations" as a > standalone > > section, but soften the language, particularly in regards to removing > > reporting as a MUST and addressing John and Ale's concerns about > requiring > > the p= value to be other than none, along with other concerns raised. > > > > A third option might come from consensus from the group, rejecting either > > of the two options I've proposed above but instead landing on a new one. > > > > Thank you for your time, and I look forward to your input. > > I've just reviewed section 8 and I find it an odd thing for an IETF > document. > I also find the notion that since my domain has a p=None policy due to the > fact > that an extremely large fraction of the email I send fails DMARC due it > being > sent to email lists translating to "I'm not doing DMARC" to be extremely > problematic. > > As I understand it, it is not typical IETF practice to do conformance > specifications. The IETF practice is to define requirements for > interoperability. > > I think that the whole section should just go. It's not the IETF's job to > specify contractual requirements for DMARC implementation. The > requirements > for this should be defined by the entity levying the requirements. Here's > an > example excerpted from a publicly available source: > > > For a domain used to send email: Registrants must publish a DMARC record > > with a reject mail receiver policy (p=reject), except during the > > implementation phase of email as described below*. > > ... > > > *When deploying DMARC during the implementation phase of email > capabilities, > > Registrants may temporarily use a “none” (p=none) or “quarantine” > > (p=quarantine) mail receiver policy, but must change the policy to reject > > for ongoing operations within 90 days of deployment. > > I know that contracts are routinely written that just say "Implement RFC > NNNN", but that is not really what RFCs are for and I don't think we > should go > down this path. > > Scott K > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
