Richard Clayton writes: > >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". > > You may wish to publish a DMARC record and do nothing else. > > You may or may not wish to provide SPF records documenting your use of > IPs -- when publishing a DMARC record. > > You may or may not wish to provide DKIM keys indicating how you sign > email -- when you are publishing a DMARC record. > > You may wish to consider DMARC when assessing incoming email and do > nothing else DMARC related. > > If you assess incoming email you may or may not wish to send reports > about what you have learnt. > > Having published a DMARC record you may or may not wish to request that > others put effort into sending you reports.
That would be fine for experimental protocol, but when we are talking to standard track document you need to have some mandatory to implement features. This document really should concentrate on the mail receiver end, as that is where the interoperability and implementation issues are. Publishing DMARC, SPF, DKIM records in DNS are all using the protocol they are not about implementations. We do not mandate the use of the protocols. SPF, and DKIM record formats, and how to geenrate them are all described in other RFCs. Only thing for doman owner is that if they use DMARC and publish DMARC dns records they format DMARC DNS entry as specified in this standard. For mail receivers there is more interoperability requirements, i.e., find the DMARC records from the DNS, parse them, do tree walk, do SPF and DKIM processing, and do final DMARC processing. Protocols do require mandatory to implement features, to make sure they are interoperable, and in this case I think we need to say that DKIM is MUST and SPF is MAY, or that both DKIM and SPF is MUST. Otherwise there is possibility that sender uses only one of them and receiver another and there is no interoparbility with those two sets. > >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. > > In each case I set out, there will be a MUSTs to consider when > configuring your system, but in the alternative you will ignore the MUST > as inapplicable given your level of engagement. Hence the necessity for > conditional statements throughout -- to keep the protocol police at bay. We do not give requirements for configuring the system, we only give requirements for mandatory to implement features. Even when you have specific set of requirements you MUST implement, there is no requirement that those MUST be used, but if adminstrator wants to use them he/she MUST be able to configure those to be used if the product he/she is using claims to support standard track RFC. -- [email protected] _______________________________________________ dmarc mailing list -- [email protected] To unsubscribe send an email to [email protected]
