I don't think this is the place to tell mailing lists what to do, and that's all discussed in Section 4.1.3 of RFC 7960.
Barry On Thu, Jul 6, 2023 at 11:48 AM Alessandro Vesely <[email protected]> wrote: > > Hi, > > the only issue I'd put about the new section is that it doesn't mention From: > munging. Isn't that practice widespread enough that it deserves being > considered? > > > Best > Ale > > > On Thu 06/Jul/2023 16:55:02 +0200 Barry Leiba wrote: > > 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 [email protected] (an > > address that relays the messages to another address with a real > > mailbox) or [email protected] (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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
