https://trac.ietf.org/trac/dmarc/ticket/66
When this issue was first raised on the list back in June, it seemed that consensus might've landed on the idea that this should be written up in a separate BCP, rather than be part of the DMARC bis effort itself. I'm concerned, however, that there might not be enough there there to warrant a separate BCP, and to that end I've taken a stab at modifying the base DMARC document, specifically Section 8, Implementation, as follows: ------------------------------------------------------------------------------------------------------------------------- 8 <https://tools.ietf.org/html/rfc7489#section-8>. Implementations The characteristics of a DMARC implementation will vary for the different roles in the messaging infrastructure. 8.1 Domain Owner Implementations Section 6.5 <https://tools.ietf.org/html/rfc7489#section-6.5> describes many of the provisions for implementing the DMARC mechanism as a Domain Owner. This section will clarify those needed for minimal and full implementations. 8.1.1 Minimal Domain Owner Implementation The only action required for minimal implementation of the DMARC mechanism by a Domain Owner is the creation of the DMARC policy record in DNS. 8.1.2 Full Domain Owner Implementation Full implementation of the DMARC mechanism by a Domain Owner requires all of the following characteristics: - Creation of the DMARC policy record in DNS which meets these criteria: - The policy record MUST express a Requested Mail Receiver policy of “quarantine” or “reject” for the Organizational Domain and all sub-domains - The Requested Mail Receiver policy MUST apply to a percentage of mail not less than 100 - Establishment of an address to receive aggregate reports at least daily; other than in exceptional circumstances such as resource exhaustion, the address must support receiving reports up to at least ten megabytes in size. - Deployment of authentication technologies to ensure Identifier Alignment 8.2 Mail Receiver Implementations This section will describe minimal and full implementations of the DMARC mechanism for Mail Receivers. 8.2.1 Minimal Mail Receiver Implementation Minimal implementation of the DMARC mechanism by a Mail Receiver means fully implementing the provisions of Section 6.6 <https://tools.ietf.org/html/rfc7489#section-6.6> 8.2.2 Full Mail Receiver Implementation Full implementation of the DMARC mechanism by a Mail Receiver is defined by the following characteristics: - Fully implementing the provisions of Section 6.6 <https://tools.ietf.org/html/rfc7489#section-6.6> - Validation of any ARC header sets found in the message - Enforcement of discovered policies in a manner that is consistent with Section 6.7 <https://tools.ietf.org/html/rfc7489#section-6.7> - Send aggregate reports at least daily using “mailto” URIs; such aggregate reports MUST be no larger than ten megabytes in size. 8.3 Report Receiver Implementations The following implementations are defined for operators that receive reports about messages related to another operator. Implementations for Domain Owners that receive reports about their own messages are described in Section 8.1. 8.3.1 Full Report Receiver Implementation Full implementation of the DMARC mechanism by a Report Receiver means establishment of an address to receive aggregate reports at least daily; other than in exceptional circumstances such as resource exhaustion, the address must support receiving reports up to at least ten megabytes in size.. 8.4 Intermediary Implementations The term “Intermediary” is meant to encompass Mediators, Relays, and Gateways as defined in [EMAIL-ARCH <https://tools.ietf.org/html/rfc7489#ref-EMAIL-ARCH>]. This section will describe minimal and full implementations for Intermediaries. 8.4.1 Minimal Intermediary Implementation Minimal implementation of the DMARC mechanism by an Intermediary means fully implementing the provisions of Section 6.6 <https://tools.ietf.org/html/rfc7489#section-6.6> 8.4.2 Full Intermediary Implementation Full implementation of the DMARC mechanism by an Intermediary is defined by the following characteristics: - Fully implementing the provisions of Section 6.6 <https://tools.ietf.org/html/rfc7489#section-6.6> - Attaching a complete and valid ARC Set of headers to the message - Enforcement of discovered policies in a manner that is consistent with Section 6.7 <https://tools.ietf.org/html/rfc7489#section-6.7> - Send aggregate reports at least daily using “mailto” URIs; such aggregate reports MUST be no larger than ten megabytes in size ------------------------------------------------------------------------------------------------------------------------- Thank you for reading, and I look forward to any and all comments and discussion. -- *Todd Herr* | Sr. Technical Program Manager *e:* [email protected] *p:* 703.220.4153 This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
