Richard Clayton writes: > -----BEGIN PGP SIGNED MESSAGE----- > >It says: > > > > ... A Mail Receiver MUST implement > > support for a "mailto:"; URI, i.e., the ability to send a DMARC > > report via electronic mail. > > > >both for rua and ruf tags, so I think that is supposed to mean that > >mailto urls are mandatory to implement for sending reports. > > so it does ... that's clearly not nuanced enough. It needs to say > something like a "Mail Receiver participating in DMARC MUST ..." > > can the editors please fix that.
Why? This document is documenting DMARC, everybody who implement this is participating in DMARC, so we do not need to add those extra words. If you are not participating in DMARC, do not implement or read this specification. If you do want to implement DMARC, you do all the MUSTs listed in this specification and there is no need to say that "if you implement this RFC, you MUST do x". > >It does not seem to say that sending reports is mandatory, > > and clearly it ought not to. There's "participating in DMARC" wording > elsewhere in the document to cover this sort of thing And I think those "participating in DMARC" words needs to be removed. They are not needed. Everybody implementing things based on this specification are "participating in DMARC", so we do not need to add that to every single statement. > >> > - MUST store authentication results for eventual presentation back > >> > to the domain owner. (5.3.7) > >> > >> you have missed out a conditionality.. there is no requirement in the > >> document to create aggregate feedback results. > > > >Ok, so the 5.3.7 MUST is wrong, it is SHOULD, not MUST, if there is > >condition where it does not apply. > > the condition is at the start of 5.3.7 ... the very first few words > > >So changing 5.3.7 from: > > > >---------------------------------------------------------------------- > >5.3.7. Store Results of DMARC Processing > > > > If the Mail Receiver intends to fully participate in DMARC, then > > results obtained from the application of the DMARC mechanism by the > > Mail Receiver MUST be stored for eventual presentation back to the > > Domain Owner in the form of aggregate feedback reports. Section 4.7 > > and [I-D.ietf-dmarc-aggregate-reporting] discuss aggregate feedback. > >---------------------------------------------------------------------- > > which you have helpfully quoted... so there's no need to change that IMO I think strongly that this needs to be made proper SHOULD, if it is suppoed to be such, or if it is supposed to be MUST, the condition needs to be removed. > >If you have MUST with condition that is SHOULD. And having condition > >of "intends to fully participate" is not very good condition... > > > >> > - MUST NOT reject incoming messges solely on the basis of a > >> > p=reject. (7.4) > >> > >> there is a SHOULD NOT in this section > > > >There is SHOULD in 2nd block marked with '|', but the 3rd block > >includes MUST NOT. > > sigh ... I really ought to read what people actually put in documents > rather than what the mailing list discussion concludes... > > > The text I am referencing is: > > > >---------------------------------------------------------------------- > >7.4. Interoperability Considerations > >... > > | It is therefore critical that Mail Receivers MUST NOT reject > > | incoming messages solely on the basis of a "p=reject" policy by > > | the sending domain. Mail Receivers must use the DMARC policy as > > | part of their disposition decision, along with other knowledge and > > | analysis. > > I always understood that "MUST NOT except when you have thought about > it" was spelled "SHOULD NOT". Why does this draft not follow that > approach ? There is no exceptions there. It is proper MUST. All Mail Receivers MSUT NOT reject incoming messages just because they have p=reject. > > In the absence of > > | other knowledge and analysis, Mail Receivers MUST treat such > > | failing mail as if the policy were "p=quarantine" rather than > > | "p=reject". > > and again "MUST except when you have thunk" is spelled "SHOULD" There is no exceptions there. It says you MUST do other checks also, and if and only if those say otherwise you needs to treat p=reject as p=quarantine. > I went back and read RFC2119 and my memory appears to be correct. There is no exceptions in those statements. You MUST or MUST NOT do what the specification says, i.e., you MUST do other checks in addition to p=reject. If those other checks do not give you extra knowledge that would indicate you can treat p=reject as p=reject, you treat it as p=quarantine. > >This is the exact reason I think we DO NEED conformance requirements > >section... We can't have this kind of ambiguity about mandatory to > >implement features. > > I think we just need some words spelled correctly. Which is very big issue when we are talking about what is mandatory to implement and what is not. -- kivi...@iki.fi _______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
