On 20 Nov 2024, at 14:06, The IESG wrote:
The IESG has received a request from the Domain-based Message
Authentication,
Reporting & Conformance WG (dmarc) to consider the following document:
-
'Domain-based Message Authentication, Reporting, and Conformance
(DMARC)'
<draft-ietf-dmarc-dmarcbis-36.txt> as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits
final
comments on this action. Please send substantive comments to the
[email protected] mailing lists by 2024-12-04. Exceptionally,
comments may
be sent to [email protected] instead. In either case, please retain the
beginning
of the Subject line to allow automated sorting.
In anticipation of IETF Last Call, I sent (roughly) the below comments
to the dmarc mailing list some time back. While these comments largely
do not represent the rough consensus of the working group, they’re
important for IESG to consider in deciding how to act on this document.
I will use the health care industry “safe and effective” analogy
here.
Safety
------
Deployment of the first iteration of DMARC has resulted in significant
deployment problems, interfering with the delivery of some email from
domains with a p=strict or p=quarantine policy. Examples are:
* Inappropriate use of p=reject and p=quarantine — Many domains
publish restrictive policies in an effort to suppress misuse of their
domain names, without regard for usage patterns. A number of online
tools warn users and domain administrators that their domains aren’t
fully protected if they don’t have a restricted policy, without regard
to how the domain is used. Blanket policies, like DHS [BOD
18-01](https://www.cisa.gov/news-events/directives/bod-18-01-enhance-email-and-web-security),
require restrictive policies for a wide range of domains (in this case
for all US Government agencies). It is unlikely that the publication of
DMARCbis will rectify either of these things.
* Mailing lists — Mailing list operators, including ietf.org, have
had to implement rewriting of From addresses such as
[[email protected]](mailto:[email protected]) becomes
[[email protected]](mailto:[email protected])
when a p=strict or p=quarantine policy is in place. This works to some
extent for IETF, but there is an enormous number of mailing list
operators, each of whom would need to implement address rewriting. While
address rewriting is not the recommended solution, it is widely used
because of the widespread inappropriate use described above.
* Receive-side forwarders — Many receive-side forwarders (e.g.,
alumni and organizational domains providing affinity email addresses)
preserve the integrity of DKIM signatures, but not all do. This is
similar to the mailing list problem, except that it is more likely to
occur even with domains used only for transactional email, which is
otherwise one of the more promising use cases for DMARC.
Effectiveness
-------------
There are also factors that call into question whether DMARC(-bis) does
what it purports to do (protecting the domain name), or whether that is
valuable:
* Visibility of domain names — One of the justifications given for
DMARC deployment is to protect the sender’s domain name: to prevent
attackers from spoofing the From address of addresses in that domain.
But many mail user agents (an increasing number, it seems) do not
display the sender’s email address, only the friendly name. In some
cases, the recipient can request to see the message header or source,
but this requires specific effort and would normally only be done when
the user considers a message to be suspicious. I regularly receive
messages claiming to be from a bank, a well-known brand, or even from
myself, but with a completely unrelated email address. These messages
pass DMARC (because the domain in the From address is controlled by the
fraudulent sender or has no DMARC record) but are still effective as
potential phishing messages. As noted in Section 10.4 “Display Name
Attacks”, these are considered out of scope for DMARC.
* Normalization of rewriting — The rewriting of From addresses
described above might serve to accustom users to From address rewriting.
Messages with email addresses that look like they have been rewritten
can easily be used by attackers to bypass DMARC policies and reporting.
General
-------
The DMARC charter calls for “Addressing the issues with indirect mail
flows” and lists several approaches to do that. DMARCbis discusses the
issues in Section 7.4, but doesn’t address them other than to
recommend that p=reject not be used when users subscribe to mailing
lists. This is really no different from the situation with existing
DMARC. It’s also not possible to implement this recommendation for
receive-side forwarders, where even transactional senders would
generally not know that a forwarder is being used. ARC (RFC 8617,
experimental) has been discussed as a possible approach here, but as
noted at the end of Section 7.4, has not achieved wide enough use to be
useful here.
In 2013, a similar protocol, ADSP \[RFC5617\], was
[changed](https://datatracker.ietf.org/doc/status-change-adsp-rfc5617-to-historic/)
from standards track to historic, citing limited use and harm caused by
incorrect configuration very similar to the inappropriate use of
p=reject described above. While DMARC has had considerably more use than
ADSP, the harm that has been caused by DMARC is correspondingly higher.
Considering the above problems, DMARCbis is neither safe nor effective.
It should not be published as a standards track document by IETF.
\-Jim
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
