Internet DRAFT - draft-levine-dmarc-listugh
draft-levine-dmarc-listugh
Network Working Group J. Levine
Internet-Draft Standcore LLC
Intended status: Informational 15 August 2023
Expires: 16 February 2024
Mailing lists and mail forwarders vs. DMARC
draft-levine-dmarc-listugh-01
Abstract
DMARC introduced an authentication system intended to detect and
deter domain name impersonation in mail message From header fields.
Unfortunately, DMARC also has caused severe damage to mail forwarders
and discussion lists. We describe the damage and some of the
workarounds.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 16 February 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Levine Expires 16 February 2024 [Page 1]
Internet-Draft Lists vs DMARC August 2023
Table of Contents
1. DMARC alignment and policies . . . . . . . . . . . . . . . . 2
2. Forwarding failures . . . . . . . . . . . . . . . . . . . . . 2
3. Mailing list failures . . . . . . . . . . . . . . . . . . . . 3
4. Workarounds . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. Irreversible From rewrites . . . . . . . . . . . . . . . 4
4.2. Reversible From rewrites . . . . . . . . . . . . . . . . 5
4.3. Message wrapping . . . . . . . . . . . . . . . . . . . . 5
4.4. List unmunging . . . . . . . . . . . . . . . . . . . . . 6
4.5. ARC . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Informative References . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. DMARC alignment and policies
DMARC[RFC7489] introduced an authentication system intended to detect
and deter domain name impersonation in mail message From header
fields. DMARC says that the address in a message's From header is
"aligned" if the message also has a valid DKIM[RFC6376] signature
with the same domain, or the message's RFC5321.MailFrom[RFC5598]
(which we'll call the MailFrom) is in the same domain and it passes
SPF[RFC7208] checks. (This is somewhat oversimplified but close
enough for our purposes. See [RFC7489] for all the details.)
Each domain can publish a DMARC record with a policy advising
recipients what to do if the receive a message with the domain in the
From header that is unaligned. The policy options are "none" for do
nothing special, "quarantine" to mark the message as dubious
typically by putting it in a spam folder, or "reject" to reject the
message in the SMTP session.
At this point most large mail systems follow senders' DMARC policy
advice most or all of the time. While this definitely deters a lot
of phishing attempts, it also makes a lot of long standing mail
practices fail.
2. Forwarding failures
Forwarding is a standard feature of Internet mail. One can send a
message to one address that is then remailed to a different address.
Common use cases are that someone moved from one organization to
another and the mail follows her for a while, a school or
professional organization offers a mail address that won't change
even if someone changes mail providers, or (as at the IETF) a role
address forwards to the people currently handling the role.
Levine Expires 16 February 2024 [Page 2]
Internet-Draft Lists vs DMARC August 2023
DMARC makes forwarding fail in two ways. If a message is only
aligned using SPF, remailing will make subsequent SPF checks fail
since the message is now sent from the IP address of the forwarder,
not the original sender. The remailer can fix the SPF failure by
replacing the MailFrom with one in its own domain, but since that
domain is different from the From header domain, there's no DMARC
alignment.
DKIM was designed to survive forwarding since it does not depend on
the path that the message takes. Nonetheless, forwarded DKIM signed
messages sometimes fail because the forwarding system modifies the
message in ways that break DKIM signatures. Some mail systems tidy
up message headers by rewrapping them or adjusting spacing, which
will make DKIM validation fail if the signature uses the default
"simple" algorithm but still succeed if it uses the optional
"relaxed" one. (This makes debugging intermittent DMARC failures a
challenge.) Sometimes forwarding systems add a tag to the end of the
message which will also break the DKIM signature.
When a forwarded message fails DMARC alignment, it might disappear
into the recipient's spam folder if the sender policy is
"quarantine", or reject at the end of the SMTP session it if the
policy is "reject". The rejection report might bounce back to the
forwarder, or to the original sender depending on what tne MailFrom
is.
Adding to the confusion, some mail systems such as Gmail look with
disfavor on unauthenticated messages, independent of DMARC. This
means that a forwarded message without a valid DKIM signature and
that fails SPF due to forwarding is likely to get misfiled as spam.
3. Mailing list failures
When mail transits a mailing list using a list manager such as
Mailman or Sympa, messages suffer all of the DMARC problems of
forwarded mail, and many more.
Lists invariably replace the MailFrom with the list manager's
address, so the list gets any bounce messages and can use them to
prune dead addresses. This means any messages that only used SPF
validation invariably fail DMARC alignment.
Lists usually change the contents of the message, adding tags to
subject lines, and headers and footers to message bodies. Some lists
make even larger edits, reordering or removing MIME parts, or
flattening HTML to text. All of these changes invalidate DKIM
signatures.
Levine Expires 16 February 2024 [Page 3]
Internet-Draft Lists vs DMARC August 2023
When a message from a mailing list fails DMARC alignment, all of the
problems of forwarded messages are possible, along with a worse one,
getting bounced off a list. Mailing list software collects bounce
messages, and after some number of bounces (adjustable by heuristics
and configuration), a subscriber is removed from the list. This can
happen to any subscriber using a mail system that follows DMARC
p=reject policy, regardless of what policy their own system
publishes; any message from a domain with a p=reject policy provokes
this problem.
4. Workarounds
Painful experience has shown that telling mail system operators about
the problems caused by their overly strict DMARC policies rarely
helps. ("It must be your problem, it works for everyone else.")
Forwarders and particularly mailing lists have come up with a variety
of workarounds to try and get the mail delivered, with more or less
severe costs to usability.
4.1. Irreversible From rewrites
The most common mailing list workaround is to replace the address in
the From header with the list's address. The MailFrom is in the same
domain, which provides SPF validated DMARC alignment, and lists often
apply their own DKIM signatures which provides DKIM validated
alignment.
This makes it harder to tell who originally sent the message. Some
lists put the author's name or address in the From header comment,
but some don't. On lists that don't, it is often impossible to tell
who sent a message unless they happen to put their name in the
message body. Some lists put the author's address in the Reply-To
header, which makes it possible to respond to the author but also
makes the default response private rather than to the list, which is
rarely what list users want.
For forwarded SPF validated message, mail systems can replace the
MailFrom with the forwarder's address. This provides valid SPF but
if the final delivery fails, there is no way for the original sender
to find out. In the frequent case where the forwarder is an address
that nobody looks at, it means that the bounces are unlikely to be
noticed or acted on.
Levine Expires 16 February 2024 [Page 4]
Internet-Draft Lists vs DMARC August 2023
4.2. Reversible From rewrites
When the local mail system allows, a less bad approach is to rewrite
the From address into an address in the local domain and add a DKIM
signature from the rewritten domain in a way that makes it possible
to recover the original address. For example, my original
implementation would rewrite steve@aol.com to
steve@aol.com.dmarc.fail. The IETF's mail system would rewrite it to
steve=40aol.com@dmarc.ietf.org. LISTSERV uses an opaque hash,
something like 18a1298287d8@listserv.com. In each case, the mail
system sets up a temporary forward so mail to the rewritten address
is mailed back to the original author.
This largely preserves the regular list semantics at the cost of the
rewritten addresses ending up in users' address books, and the same
forwarding problems when the responses are forwarded back. For this
approach to be workable, the mailing list operator has to have enough
control over the underlying mail system to manage the rewritten
addresses and forwards. If as is often the case the list is on a
shared server with a mail system run by someone else, this approach
isn't practical.
For mail forwarding, the SPF analog is known as Sender Rewriting
Scheme (SRS) which would rewrite the address to
SRS0=HHH=TT=aol.com=steve@forwarder.com where HHH is a validation
hash and TT is a timestamp. SRS was proposed around 2003 but has
never been widely used.
4.3. Message wrapping
A different approach is to wrap the original message in an outer
message from the list or forwarder. The original message might be
wrapped as a single message/rfc822 body part, or as message/rfc822
inside multipart/digest, a one entry message digest. The outer
message has the list's address in the From header, DKIM signature,
and MailFrom, so it sails through DMARC alignment. The problem is
what happens when recipients try to read the message.
Some desktop mail programs deal with wrapped or digest messages
fairly well, presenting the internal messages as real messages, some
are so-so, attachments you can click on to see the internal messages,
and some badly, without showing the internal message as separate from
the wrapper, with no way to reply to the internal message short of
cutting and pasting the subject and addresses by hand.
Levine Expires 16 February 2024 [Page 5]
Internet-Draft Lists vs DMARC August 2023
Web mail consistently handles wrapped messages badly. I have never
seen a web mail system that allowed responses to wrapped or digest
messages. (Mailing list users are all too familiar with this
problem, with replies typically starting "Re: foo list digest, Vol
42, No 17".)
4.4. List unmunging
There have been some attempts to allow mailing lists to describe the
modifications they make to messages on the way through, such as
[I-D.chuang-mailing-list-modifications]. The idea is that recipient
systems can undo the changes and revalidate the original message to
check for DMARC alignment.
This may or may not be practical this is for several reasons. One is
that lists make a lot of different kinds of changes, so it may not he
possible to describe enough of them to be useful. More important,
this depends on the recipient deciding when the modified message is
"too different" to accept. In an extrme case, a malicious list might
completely replace the original body with spam, or use HTML coding
tricks to make the original body invisible and just show the added
spam.
4.5. ARC
ARC[RFC8617] is intended to allow forwarding mail system to include
the authentication history of a message. Each forwarding system adds
a signed group of ARC headers which includes the authentication
results of the message as it arrived at that system. This lets a
recipient system look at the ARC headers on a mailing list message,
see if it was DMARC aligned when it arrived at the list host, and
treat the message as aligned even if it no longer is. The main
limitation of ARC is that there is no technical bar to signing fake
authentication results, so one can only use ARC headers from
trustworthy forwarders. While it's not hard for large systems to use
existing reputation data to decide who is trustworthy, it's a problem
for small systems.
ARC was designed in 2019 and many mail systems including Gmail and
Outlook add ARC headers. Some mail systems such as Microsoft's allow
administrators to configure lists of acceptable ARC forwarders, but
none to my knowledge do so by default. It remains unclear what the
practical barriers to adoption, beyond the forwarder reputation, are.
5. Informative References
Levine Expires 16 February 2024 [Page 6]
Internet-Draft Lists vs DMARC August 2023
[I-D.chuang-mailing-list-modifications]
Chuang, W., "Tolerating Mailing-List Modifications", Work
in Progress, Internet-Draft, draft-chuang-mailing-list-
modifications-03, 13 August 2023,
<https://datatracker.ietf.org/api/v1/doc/document/draft-
chuang-mailing-list-modifications/>.
[RFC5598] Crocker, D., "Internet Mail Architecture", RFC 5598,
DOI 10.17487/RFC5598, July 2009,
<https://www.rfc-editor.org/info/rfc5598>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for
Authorizing Use of Domains in Email, Version 1", RFC 7208,
DOI 10.17487/RFC7208, April 2014,
<https://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
Message Authentication, Reporting, and Conformance
(DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
<https://www.rfc-editor.org/info/rfc7489>.
[RFC8617] Andersen, K., Long, B., Ed., Blank, S., Ed., and M.
Kucherawy, Ed., "The Authenticated Received Chain (ARC)
Protocol", RFC 8617, DOI 10.17487/RFC8617, July 2019,
<https://www.rfc-editor.org/info/rfc8617>.
Author's Address
John Levine
Standcore LLC
Email: standards@standcore.com
Levine Expires 16 February 2024 [Page 7]
