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 StandardThe IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@xxxxxxxx mailing lists by 2024-12-04. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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, 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 user@xxxxxxxxxxx becomes user=40example.com@xxxxxxxxxxxxxx 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 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
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
