On Fri 21/Aug/2020 21:25:50 +0200 Todd Herr wrote: > https://trac.ietf.org/trac/dmarc/ticket/66
It seems to me it is a bit too early to consider this issue. > 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: I'm not yet clear about how many documents will the WG end up with. > ------------------------------------------------------------------------------------------------------------------------- > 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. I'd start by introducing the distinction between domain owner and mail receiver. A statement should then say what is the combined minimal/ full implementation. > 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. Ok. > 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 > - Nope. A domain can say it has a *strict policy* when the above criteria are met. Standing the principle that domains which host human users mailboxes must not publish a strict policy, mandating that these domains don't fully implement DMARC makes little sense. Note that I'm opposed to said principle, which is a limitation of DMARC. However, the limitation is there and we must first remove it. Afterwards, perhaps, we can mandate strict policies. > 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 Isn't it clearer to say "both SPF and DKIM"? > 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> Maybe a minimal implementation could skip storing the results of DMARC processing. > 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> Ok. > - > > Validation of any ARC header sets found in the message Nope. DMARC has nothing to do with ARC. > - > > Enforcement of discovered policies in a manner that is consistent > with Section > 6.7 <https://tools.ietf.org/html/rfc7489#section-6.7> Hm... that adds nothing to the requirements. Section 6.7 allows receivers to do what they see fit. > - > > Send aggregate reports at least daily using “mailto” URIs; such > aggregate reports MUST be no larger than ten megabytes in size. I'd just mandate reporting. Size is a different issue. Limiting the size makes more sense for each mailto: address, as it should reflect message size limits that the corresponding MTA enforces. See also ticket #53. Some domains react to the size limit by sending multiple records for the same period. The sum of sizes exceeds the size of a single report, given the way compression works. Report size is obviously inversely proportional to frequency. How about requiring the ability to send reports hourly for full implementations and at least daily for medium ones? > 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.. Ok. > 8.4 Intermediary Implementations > I don't comment on this section, as we haven't established much about intermediaries, yet. Unless some intermediator-specific behavior is going to be defined, an intermediary implementation should be just the same as any other one. BTW, I'm not receiving reports from ietf.org. Best Ale -- _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
