As I've said before, I think we should specify what we think is right, and allow implementers to make their decisions. We can't and won't police them.
b On Thu, Jul 6, 2023 at 2:59 PM Brotman, Alex <alex_brot...@comcast.com> wrote: > > 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
