I suspect the portion that instructs receivers to not act solely on p=reject may be ignored by a fair set of receivers. I'm not necessarily opposed to the language below, just that it seems odd to create language that we know will be ignored. Additionally, I find it odd that we won't tell forwarders how to munge messages to avoid this situation, but we will tell receivers how to avoid this situation.
-- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Barry Leiba > Sent: Thursday, July 6, 2023 10:55 AM > To: IETF DMARC WG <dmarc@ietf.org> > Subject: [dmarc-ietf] Another p=reject text proposal > > I had some off-list discussions with Seth, who was very much against my > original > proposed text, and he suggested an alternative organization that would be more > palatable to him. I've attempted to set that out below. The idea is to > remove the > normative requirements about using p=reject from Sections 5.5.6 and 5.8, and > instead put a broader discussion of the issues, along with the normative > requirements, into a new "Interoperability Considerations" section. > This makes it explicitly clear that any MUST/SHOULD stuff with regard to using > and honoring p=reject is an issue of interoperating with existing Internet > email > features. I can accept that mechanism also, and so, below is my attempt at > writing that proposal up. > > Barry > > ----------------------------------------------------------------------------- > > — Section 5.5.6 — > > ADD > In making this decision it is important to understand the > interoperability issues involved and problems that can result for > mailing lists and for deliverability of legitimate mail. Those > issues are discussed in detail in the Interoperability > Considerations section [see Section x.x]. > END > > — Section 5.8 — > > OLD > Mail Receivers MAY choose to accept email that fails the DMARC > mechanism check even if the published Domain Owner Assessment Policy > is "reject". In particular, because of the considerations discussed > in [RFC7960], it is important that Mail Receivers SHOULD NOT reject > messages solely because of a published policy of "reject", but that > they apply other knowledge and analysis to avoid situations such as > rejection of legitimate messages sent in ways that DMARC cannot > describe, harm to the operation of mailing lists, and similar. > NEW > Mail Receivers MAY choose to accept email that fails the DMARC > mechanism check even if the published Domain Owner Assessment Policy > is "reject". In particular, because of the considerations discussed > in [RFC7960] and in the Interoperability Considerations section of > this document [see Section x.x], it is important that Mail Receivers > not reject messages solely because of a published policy of "reject", > but that they apply other knowledge and analysis to avoid situations > such as rejection of legitimate messages sent in ways that DMARC > cannot describe, harm to the operation of mailing lists, and similar. > END > > — New section — > > ADD > x.x Interoperability Considerations > > As discussed in “Interoperability Issues between DMARC and Indirect > Email Flows [RFC7960], use of p=reject can be incompatible with and > cause interoperability problems to indirect message flows such as > “alumni forwarders”, role-based email aliases, and mailing lists > across the Internet. > > Even a domain that expects to send only targeted messages to > account holders — a bank, for example — could have account > holders using addresses such as jo...@alumni.example.edu (an > address that relays the messages to another address with a real > mailbox) or finance@association.example (a role-based address that > does similar relaying for the current head of finance at the > association). When such mail is delivered to the actual recipient > mailbox, it will necessarily fail SPF checks, as the incoming > IP address will be that of example.edu or association.example, and > not an address authorized for the sending domain. DKIM signatures > will generally remain valid in these relay situations. > > It is therefore critical that domains that publish p=reject > MUST NOT rely solely on SPF, and MUST apply valid DKIM signatures > to their messages. > > Domains that have general users who send routine email are > particularly likely to create interoperability issues if they > publish p=reject. For example, domains that serve as mailbox hosts > and give out email addresses to the general public are best advised > to delay adoption of p=reject until the authentication ecosystem > becomes more mature and deliverability issues are better resolved. > > In particular, if users in p=reject domains post messages to > mailing lists on the Internet, those messages can cause operational > problems for the mailing lists and for the subscribers to those > lists, as explained below and in [RFC7960]. > > It is therefore critical that domains that host users who might > post messages to mailing lists SHOULD NOT publish p=reject. > Domains that choose to publish p=reject SHOULD implement > policies that their users not post to Internet mailing lists. > > As noted in [Section 5.8], receiving domains need to apply more > analysis than just DMARC evaluation in their disposition of > incoming messages. An example of the consequences of honoring > p=reject without further anaysis is that rejecting messages that > have been relayed by a mailing list can cause your own users to > have their subscriptions to that mailing list cancelled by the > list software’s automated handling of such rejections — it looks > to the list manager as though the recipient’s email address is no > longer working, so the address is automatically unsubscribed. > > It is therefore critical that receiving domains MUST NOT reject > incoming messages solely on the basis of a p=reject policy by > the sending domain. Receiving domains must use the DMARC > policy as part of their disposition decision, along with other > knowledge and analysis. > > Failure to understand and abide by these considerations can cause > legitimate, sometimes important email to be rejected, can cause > operational damage to mailing lists throughout the Internet, and > can result in trouble-desk calls and complaints from your own > employees, customers, and clients. > END > > ----------------------------------------------------------------------------- > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!!C > Ql3mcHX2A!DcF3NZ2qhT5AJ2Ui1rmR066k4kfhCPoMjiWYzY1ljS7v1f1re3kDkEYQh > 8e1lc6k3MUbxDyXwec8TqxB0THC9eRNNA$ _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
