+1 to Todd's statement, this sums up my views on this as well.
On 3/30/2023 9:16 AM, Todd Herr wrote:
On Wed, Mar 29, 2023 at 7:55 PM Barry Leiba <[email protected]>
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:*[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
