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 u...@example.com
becomes user=40example....@dmarc.ietf.org 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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
