[dmarc-ietf] Overall last-call comments on DMARC

[Jim Fenton <[e-mail]>]

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.

* Mailing lists — Mailing list operators, including ietf.org, have had 
to implement rewriting of From addresses such as [e-mail] 
becomes user=[e-mail] 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 them 
or has no DMARC record) but are still effective as potential phishing 
messages. 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

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.

Based on the above problems, I do not think DMARC-bis should be 
published as a standards track document by IETF.

-Jim