On Wed, Mar 29, 2023 at 7:55 PM Barry Leiba <barryle...@computer.org> wrote:
> 1. IETF has installed a very ugly workaround to the problem, rewriting the > "from" header field. It's absolutely a workaround, and not a proper > solution. > Ok. > > 2. Without the workaround, the real pain is not that a message from > Comcast posted to the list doesn't get to you (though that's true): the > real pain is that if Valimail rejects (bounces) those messages, the Mailman > software will eventually unsubscribe you -- YOU, not the Comcast user -- > from the list for exceeding the bounce threshold. > Thank you; this helps my understanding. > > 3. Even with the workaround, I see, as a list owner, several unsubscribe > notifications a week due to excessive bounces. > You lose me here. Are you saying that the workaround doesn't always work? Can you elaborate, please? > > The damage to mail list operations is real, and expecting every mailing > list manager to install an ugly workaround is not the right answer. > Telling those deploying DMARC what interoperability problems an > inappropriate choice of p=reject causes, and telling them not to do that... > is the right answer. > > And, as I said, when they decide that their needs are more important than > those interoperability problems, they have that right, and at least they > will now be making an informed decision. The standard needs to say this. > > I'm on board with telling those deploying DMARC what interoperability problems can be caused by a choice of p=reject, but I'm not on board with telling them not to do that. Here's why... It is my belief that there is strong support in the mailbox provider community for email authentication, because authenticated identities are stable anchors to which reputation can be attached. A current tool for establishing email authentication is DMARC, which is designed to ensure that the use of the domain in the RFC5322.From header is authorized by the domain owner. The p= tag, insofar as it has an effect on the disposition of unauthenticated mail, has never been more than a polite request by the domain owner; RFC 7489 made clear that the message receiver could honor or ignore it as it wished. What the p= tag is useful for, however, is as a signal to declare how far along a domain owner is in its journey to authenticating all mail making authorized use of its domain in the RFC5322.From header. For me, p=none means "we're sticking our toe in the water and auditing our practices through the rua reports"; p=quarantine is analogous to "we think we've got it all" (not unlike SPF's "~all"); p=reject means "we're done; if it's not authenticated, it didn't come from us". This signal can be useful to a mail receiver in deciding how much weight to give failing authentication when deciding a message's disposition. We've already got text in DMARCbis in the Policy Enforcement Considerations section that further weakens the idea that p= is even a polite request. Compare the second paragraphs of those sections: RFC 7489 Mail Receivers MAY choose to accept email that fails the DMARC mechanism check even if the Domain Owner has published a "reject" policy. Mail Receivers need to make a best effort not to increase the likelihood of accepting abusive mail if they choose not to comply with a Domain Owner's reject, against policy. At a minimum, addition of the Authentication-Results header field (see [AUTH-RESULTS <https://www.rfc-editor.org/rfc/rfc7489#ref-AUTH-RESULTS>]) is RECOMMENDED when delivery of failing mail is done. When this is done, the DNS domain name thus recorded MUST be encoded as an A-label. DMARCbis 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. My fear is that adding further text to DMARCbis that says "MUST NOT use p=reject" along with the new language in Policy Enforcement Considerations results in a spec that says: 1. As a domain owner, you can request treatment for unauthenticated mail, but your request may not (and probably will not) be honored, and by the way 2. You mustn't request treatment anyway The next step in that path is a world where the p= tag loses its usefulness as a proxy for where a domain owner is in its authentication journey, because everyone's at p=none, because DMARCbis says so. At this point, DMARC becomes useless, because one of two things happen: 1. Failed authentication loses its meaning as a signal because no one knows whose authentication policies are thought to be solid and whose aren't, or 2. Failed authentication is given more weight than it should be given because a DMARC record becomes a de facto p=reject, because no one knows whose authentication policies are thought to be solid and whose aren't Anyway, this is why I continue to support the idea of describing the interoperability issues, but opposed to the idea of telling domain owners not to use p=reject. -- *Todd Herr * | Technical Director, Standards and Ecosystem *e:* todd.h...@valimail.com *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 dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
