Mailing lists and mail forwarders vs. DMARC
draft-levine-dmarc-listugh-00

Network Working Group                                          J. Levine
Internet-Draft                                             Standcore LLC
Intended status: Informational                            13 August 2023
Expires: 14 February 2024

              Mailing lists and mail forwarders vs. DMARC
                     draft-levine-dmarc-listugh-00

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 14 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 14 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.  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 bounce address 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 14 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 bounce address 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 bounce it if the policy is "reject".  It might
   bounce back to the forwarder, or to the original sender depending on
   what tne envelope bounce address 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 bounce address 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 14 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 bounce address 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
   bounce address 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 14 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.  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 bounce address, 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 14 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.  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, but it's unclear whether any systems, even
   large ones with reputation data, are using it to avoid DMARC
   rejections, and what the barriers to adoption, beyond the forwarder
   reputation, are.

5.  Informative References

   [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>.

Levine                  Expires 14 February 2024                [Page 6]
Internet-Draft               Lists vs DMARC                  August 2023

Author's Address

   John Levine
   Standcore LLC
   Email: standards@standcore.com

Levine                  Expires 14 February 2024                [Page 7]