I'm troubled by this whole section. Unless IETF is getting into the certification or enforcement business, documenting anything about "implementation claims" would seem to be a non-starter. Do we have any similar requirements for "claims" about implementing SMTP, DNS or other standards? We should stick to the normative requirements for interoperability and avoid dealing with "claims". Folks who implement poorly will get an earful from both their mail users and the folks they interoperate with and that should be sufficient.
This really does seem like pushing on a rope. Michael Hammer On Thu, Aug 19, 2021 at 2:24 PM Todd Herr <todd.herr= [email protected]> wrote: > Greetings. > > Opening a discussion on two tickets at once, because I think they're > related, especially as presented in the current revision of DMARCbis. > > Both topics are addressed in Section 8, Minimum Implementations, which > currently reads in its entirety: > > 8. Minimum Implementations > > > Domain owners, mediators, and mail receivers can all claim to > > implement DMARC, but what that means will depend on their role in the > > transmission of mail. To remove any ambiguity from the claims, this > > document specifies the following minimum criteria that must be met > > for each agent to rightly claim to be "implementing DMARC". > > Domain Owner: To implement DMARC, a Domain Owner MUST configure its > > domain to convey its concern that unauthenticated mail be rejected or > > at least treated with suspicion. This means that it MUST publish a > > policy record that: > > > * Has a p tag with a value of 'quarantine' or 'reject' > > > * Has a rua tag with at least one valid URI > > > * If applicable, has an sp tag with a value of 'quarantine' or > > 'reject' > > > While 'none' is a syntactically valid value for both the p and sp > > tags, the practical value of either the p tag or sp tag being 'none' > > means that the Domain Owner is still gathering information about mail > > flows for the domain or sub-domains. It is not yet ready to commit > > to conveying a severity of concern for unauthenticated email using > > its domain. > > > Mediator: To implement DMARC, a mediator MUST do the following before > > passing the message to the next hop or rejecting it as appropriate: > > > * Perform DMARC validation checks on inbound mail > > > * Perform validation on any authentication checks recorded by > > previous mediators. > > > * Record the results of its authentication checks in message headers > > for consumption by later hosts. > > > Mail Receiver: To implement DMARC, a mail receiver MUST do the > > following: > > > * Perform DMARC validation checks on inbound mail > > > * Perform validation checks on any authentication check results > > recorded by mediators that handled the message prior to its > > reaching the Mail Receiver. > > > * Send aggregate reports to Domain Owners at least every 24 hours > > when a minimum of 100 messages with that domain in the > > RFC5322.From header field have been seen during the reporting > > period > > Let's discuss... > > > -- > > *Todd Herr* | Technical Director, Standards and Ecosystem > *e:* [email protected] > *m:* 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 >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
