-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In message <26448.59725.287538.334...@fireball.acr.fi>, Tero Kivinen <kivi...@iki.fi> writes >Richard Clayton writes: >> In message <26447.29429.714935.943...@fireball.acr.fi>, Tero Kivinen >> <kivi...@iki.fi> writes >> >> > Requirements for DMARC validators: >> > >> > - MUST implement mailto url for reports (4.7) >> >> I do not believe that 4.7 says that > >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. >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 [...] >> > - 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 >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 ? [....] > 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" I went back and read RFC2119 and my memory appears to be correct. >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. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBZ1D43N2nQQHFxEViEQKRhACgw0alBKpG3JZNeCfrQPvtS2MHcyQAoIo+ DgOeW/LkWykAHYlIb2Gn+zNS =LwCQ -----END PGP SIGNATURE----- _______________________________________________ dmarc mailing list -- dmarc@ietf.org To unsubscribe send an email to dmarc-le...@ietf.org
