Let me add a few comments that seem obvious to me.
On Mon 01/Apr/2024 04:00:03 +0200 Jim Fenton wrote:
In addition to the editorial review I have provided, I have significant
concerns regarding the standardization of DMARC-bis. I do not expect that the
working group rough consensus will necessarily agree with these concerns, but I
want to state them for the working group and will probably restate them for a
different audience at IETF last call.
I like to 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 DMARC-bis will rectify either of these things.
This topic is treated very well in Section 8.6, Interoperability Considerations.
* Mailing lists — Mailing list operators, including ietf.org, have had to
implement rewriting of From addresses such as [email protected] becomes
[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.
By now, most mailing lists arranged to either rewrite From: or not break DKIM
signatures. We all hope those hacks are temporary. ARC provides a protocol
whereby a mailing list can certify its behavior to an end receiver.
Unfortunately, we are still missing a protocol whereby trusting an ARC sealer
can be established by a receiver for each mail stream. We are halfway across
the ford.
* 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.
Same as above, although most forwarders don't break DKIM signatures. Whether
to rewrite the bounce address is still debatable.
## 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 them or has
no DMARC record) but are still effective as potential phishing messages. These
are considered out of scope for DMARC.
Yes. In addition, it seems that even if a MUA were able to prominently display
that a message is scam, average users would not notice it.
Presumably, we need domain reputation to address that.
* 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.
Yes.
## General
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 is correspondingly higher.
Most ADSP issues were addressed by RFC 7489. DMARC works for transactional
mail sites. If we can fix forwarding (including mailing lists) it will work
for all mail.
Based on the above problems, I do not think DMARC-bis should be published as a
standards track document by IETF.
I think the whole WG disagrees on that. Standard track is useful to mark the
way forward. Domain-based authentication is the best the whole community has
come out with to combat email abuse. I wouldn't suggest giving up.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
