[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
DMARC                                                   D.E. Foster, Ed.
Internet-Draft                                                      Self
Intended status: Informational                              October 2021
Expires: 6 April 2022


                     DMARC Compliant Mailing Lists
             draft-fosterd-dmarc-compliant-mailing-lists-00

Abstract

   Mailing Lists often make changes to a message before it is
   retransmitted.  This invalidates DKIM signatures, causing a DMARC
   test on the RFC5322.From addres to fail.  A DMARC-compliant mailing
   list is one which uses member alias addresses to identify the
   document as sent by a specific author via the mechanism of the list.
   An appropriate aliasing mechanism will not only prevent DMARC FAIL,
   but will also allow messages between members, will look natural to
   senders and recipients, and will allow list organization domains to
   advance to p=reject.  This document describes an aliasing approach
   which meets these goals.

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 4 April 2022.

Copyright Notice

   Copyright (c) 2021 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



Foster                    Expires 6 April 2022                  [Page 1]


Internet-Draft        DMARC Compliant Mailing Lists         October 2021


   and restrictions with respect to this document.  Code Components
   extracted from this document must include Simplified BSD License text
   as described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Solution Outline  . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Solution Infrastructure . . . . . . . . . . . . . . . . . . .   4
   6.  Benefits of full deployment of Group Identifiers  . . . . . .   6
     6.1.  Avoids DMARC FAIL . . . . . . . . . . . . . . . . . . . .   6
     6.2.  Enables DMARC enforcement for List-related Messages . . .   7
     6.3.  Avoids Inconsistent Delivery based on RFC5322.From domain
           filtering . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.4.  Avoids Inconsistent Delivery based on bounce-back
           Filters . . . . . . . . . . . . . . . . . . . . . . . . .   7
     6.5.  Avoids Incorrect Suspension of Member Addresses . . . . .   8
     6.6.  Available Duplicate Elimination . . . . . . . . . . . . .   8
     6.7.  Available Friendly Name Controls  . . . . . . . . . . . .   8
     6.8.  Improves List Isolation . . . . . . . . . . . . . . . . .   8
     6.9.  Permits portability . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
   10. Informative References  . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Mailing Lists often make changes to a message before it is
   retransmitted.  This invalidates DKIM signatures, causing a DMARC
   test on the RFC5322.From addres to FAIL.  This problem has created a
   standoff between mailing lists and domain owners.  Many domains which
   participate in mailing lists feel unable to publish a DMARC policy
   other than NONE, even if their messages are fully DMARC-compliant at
   origination.

   Some domain owners publish p=reject anyway, creating difficulties for
   mailing lists if their users subscribe.  In some cases, mailing lists
   allow participation by users from DMARC-enforcing domains by
   rewriting those RFC5322.From addresses, often by changing
   author@authordomain to author=authordomain@listdomain.  This
   rewriting mechanism aliases the author into the list domain, which
   avoids the DMARC FAIL result, but produces other problems.




Foster                    Expires 6 April 2022                  [Page 2]


Internet-Draft        DMARC Compliant Mailing Lists         October 2021


   Previous proposals to adddress these problems have required new
   software logic and new trust configurations for every organization
   that participates with mailing lists.  Under these proposals, success
   will depend on the list activating the new authentication signals,
   the evaluator implementing logic to check those signals, the
   evalautor trusting the list's reputation when the valid signals are
   present, and the list operator knowing that the evaluator will use
   the signals to trust list messages.  Such an outcome is difficult to
   achieve on a large scale, so it becomes necessary to seek a solution
   which is wholely in control of the mailing list operator.

   A DMARC-compliant mailing list is one which uses a permanent alias
   addresses for each member.  The alias provides subscribers with a
   stable identifier within a domain controled by the list organization.
   This identifier is implemented to allow replies to the author
   address, to look natural to senders and recipients, and to allow
   participating domains to advance to p=reject.  This document
   describes an aliasing approach which meets these goals.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Problem Statement

   Many closed-group communication systems use member identifiers which
   allow communication between members, without enabling communication
   outside of the group environment.  Examples include social networking
   products, online games, and web forums.  These environments typically
   have controls which validate member identity, controls which
   determine whether members can communicate with each other, controls
   which limit unacceptable content, and administrative monitoring to
   maintain good order.  The closed communication environment serves to
   minimize any risk assocoated with interacting with strangers.

   Email mailing lists are a hybrid environment, providing some of the
   benefits and controls of other group communication systems, but
   lacking other elements.  The benefits include an enrollment which
   establishes initial identity, sender authentication mechanisms which
   verify identity at time of submission, content filters which limit
   inappropriate messages, and list operator involvement to manage
   problems.

   On the negative side, mediators that make changes to an author's
   message arouse suspicion, since any specific change may be helpful,
   innocuous, cause misrepresentation, or cause harm.  Consequently, the



Foster                    Expires 6 April 2022                  [Page 3]


Internet-Draft        DMARC Compliant Mailing Lists         October 2021


   existence of an in-transit change means that the reputation of the
   change agent is more important than the reputation of the originator.
   This is even more applicable for mediators that can be trusted to
   have checked source identity, source reputation, and content risk
   before determining that the message can be forwarded.

   For the reputation of the mediator to be the focus of attention by
   mediators which use existing evaluation strategies, the RFC5322.From
   address must point to the mediator organization and should be signed
   by the mediator organization.  In short, the message must produce
   DMARC PASS.  The purpose of From-rewrite is not to fix a defect in
   the design of DKIM or DMARC, but rather to point the evaluator to the
   organization most responsible for the final state of the document.

4.  Solution Outline

   List members are given a permanent alias email address, within the
   list organization.  When list messages are transmitted from the
   Mailing List Management software (MLM), or between list members, the
   author's actual email address is rewritten with the author's member
   alias.  When messages are destined to a member alias address, the
   RFC5321.RcptTo address is rewritten with the member's actual email
   address.  Because the alias email address is registered and
   permanent, and supported by necessary infrastructure, it can be used
   for member-to-member communication.

   For technical reasons, the alias addresses should use a dedicated
   subdomain within the list organization.  A single subdomain could be
   used for multiple mailing lists, or each list could have its own
   subdomain, based on organizational preference and technical
   considerations.  For domain example.com, a shared alias domain could
   be "authoralias@lists.example.com" while a list-specific alias domain
   could be "authoralias@techtopics.example.com"

   After a member is unsubscribed, his alias should not be reused,
   except to reinstate that member, so that there is no identity
   confusion between past and present subscribers.

   These features require interoperability between the list enrollment
   process, where list member aliases are configured, and the mail
   processing gateways where address replacement occurs.

5.  Solution Infrastructure

   Several infrastructure additions are needed to support the alias
   implementation.





Foster                    Expires 6 April 2022                  [Page 4]


Internet-Draft        DMARC Compliant Mailing Lists         October 2021


   *  List enrollment processes are needed to select an alias for each
      subscriber and verify that the alias is unique and not previously
      used.  Additioinally, the translation table of actual address to
      alias address must be published for use by the rewriting gateways.

   *  A new server or function module is necessary to rewrite the From
      address on messages posted to the list, and then apply a DKIM
      signature.

   *  A new message flow path is necessary for member-to-member
      communication using the list alias domain.

   The first diagram illustrates a possible mailing list configuration
   without aliasing.  Messages flow in through the incoming gateway, and
   are forwarded to the list domain mail store.  Mailing List
   Managerment (MLM) software processes messages for the list address,
   and replicates accepted messages to all recipients.  Both internal
   and external recipients can be delivered to the mail store for
   delivery or forwarding.  Optionally, list messages may be archived.

   +----------------+  +-------------+  +--------------+
   | List Domain MX |->| List Domain |->| List Domain  |
   | Inbound Gwy    |  | Mail Store  |  | Outbound Gwy |
   +----------------+  +-------------+  +--------------+
                         In |     | Out
   +----------------+  +--------------+
   | Journal/Audit  |<-| Mailing List |
   | /Archive (opt) |  | Manager      |
   +----------------+  +--------------+|

                                  Figure 1

   The second diagram illustrates a possible mailing list configuration
   after aliasing is enabled.  Messages flow in through the incoming
   gateway, and are forwarded to the list domain mail store.  Mailing
   List Managerment (MLM) software processes messages for the list
   address, and replicates accepted messages to all recipients.
   Outbound messages are forwarded to a smarthost server which performs
   rewriting of the From address, based on an actual-to-alias address
   translation table published from the MLM.  Additionally, a DKIM
   signature is applied once all rewriting has been completed.  Finally,
   messages are relayed to an appropriate server or gateway for
   delivery.








Foster                    Expires 6 April 2022                  [Page 5]


Internet-Draft        DMARC Compliant Mailing Lists         October 2021


   +---------------------+   +----------------+  +----------+
   | List Alias MX       |-->| From Address   |->| Outbound |
   | Inbound Gwy         |   | Rewrite Server |  | Gateway  |
   | MailFrom-RcptTo chk |   +----------------+  +----------+
   | Receiver rewrite    |     |In
   | Content Filters     |   +----------------+
   +---------------------+   | Journal/Audit  |
                             | /Archive (opt) |
                             +----------------+

                                  Figure 2

   The third diagram illustrates a possible mailing configuration of the
   alias domain used for member-to-member messages.  The incoming
   gateway has the most complexity.  It validates the sender identity,
   verifies that the sender actual address and receiver alias addrss are
   subscribers to a common list, translates the recipient address to an
   actual address, and performs content filtering.  Accepted messages
   are forwarded to a smarthost server for rewriting of the From address
   and application of a DKIM signature.  This may be the same smarthost
   server used for outbound messages from the MLM.  Based on list owner
   policy, messages or message characteristics may be captured for audit
   or archive purposes.  Finally messages are relayed to an appropriate
   server or gateway for delivery.

   +---------------------+   +----------------+  +----------+
   | List Alias MX       |-->| From Address   |->| Outbound |
   | Inbound Gwy         |   | Rewrite Server |  | Gateway  |
   | MailFrom-RcptTo chk |   +----------------+  +----------+
   | Receiver rewrite    |     |In
   | Content Filters     |   +----------------+
   +---------------------+   | Journal/Audit  |
                             | /Archive (opt) |
                             +----------------+

                                  Figure 3

6.  Benefits of full deployment of Group Identifiers

   While any aliasing scheme could be rolled out on a limited basis to
   only some subscribers, the benefits of aliasing are maximized when
   all members are configured with aliases.

6.1.  Avoids DMARC FAIL

   As has been well documented, a list without aliasing can encounter
   problems when the author domain enforces DMARC.




Foster                    Expires 6 April 2022                  [Page 6]


Internet-Draft        DMARC Compliant Mailing Lists         October 2021


6.2.  Enables DMARC enforcement for List-related Messages

   Without aliasing, a list message can be easily spoofed by an
   attacker.  The attacker need only know a list to which the victim
   subscribes, the visual characteristics of the list message, and an
   RFC5322.From domain which does not enforce DMARC.  Incoming email
   filters will see an SPF PASS based on the attacker domain, and a From
   domain without DMARC policy.  Unless the message is blocked based on
   attacker domain reputation or content filtering, the spoofed message
   will be released to the victim.  Similarly, the victim recipient will
   have no visual clues to raise suspicion.

   Once a list migrates to aliases for all subscribers, list messages
   will be from the list organization, list messages will earn DMARC
   PASS, and list-related domains can be protected with DMARC p=reject
   to ensure that spoofing attempts are hindered.  Recipients will have
   the visual clue that list-related messages always come from a
   specific domain within the list organization.

6.3.  Avoids Inconsistent Delivery based on RFC5322.From domain
      filtering

   Some evaluators will filter messages based on the RFC5322.From
   address.  Most commonly, this is used to block addresses from
   unexpected or untrusted geographies and domains.  A mailing list may
   have a more diverse participation than these filters expect.  Without
   aliasing, some list messages may be blocked by these filters.  The
   subscriber is likely to perceive these missing mesage events as
   strangely random.  Even when the cause is identified, an acceptable
   resolution may not exist, since the evaluator cannot know the set of
   all necessary exceptions for all present and future list subscribers.

   When aliasing is enabled, any filtering performed by the recipient
   system on the RFC5322.From address will see a list organization
   domain, rather than an author domain.  This helps to ensure that list
   messages are delivered consistently.  If list messages are
   inappropriately blocked by content filtering, the recipient system
   manager can safely implement a whitelist rule based on the DMARC-
   verifiable From domain.

6.4.  Avoids Inconsistent Delivery based on bounce-back Filters

   Some evaluators will block external messages that claim to be from an
   internal domain, when the evaluator does not check DMARC or the
   sender domain does not enforce DMARC.  List posts will always
   generate these bounce-back messages, because the post is relayed back
   to the author and may also be sent to other subscribers in the same
   domaion as the author.  With aliasing, messages are never be blocked



Foster                    Expires 6 April 2022                  [Page 7]


Internet-Draft        DMARC Compliant Mailing Lists         October 2021


   by such filters, because list-related messages will always be from
   the list organization, not the author's organization.

6.5.  Avoids Incorrect Suspension of Member Addresses

   If a message is inappropriately blocked for any of the above reasons,
   the mailing list management software may detect the block as a reason
   to disable the recipient account from future deliveries.  By avoiding
   false blocks, the list also avoids false account suspensions.

6.6.  Available Duplicate Elimination

   When a user chooses "Reply All" to a list msessage, the author
   receives one copy to his own address and one copy from the list
   expansion.  With aliasing, the incoming gateway will see both names,
   and can optionally be configured to suppress the duplication.

6.7.  Available Friendly Name Controls

   When an alias name is registered, the subscription process could also
   collect a Friendly Name to use along with the alias name.  When an
   RFC5322.From address is replaced with an alias, the registered
   Friendly Name could be inserted as well.  This standardization may
   help avoid subscriber reconfiguration of the Friendly Name to insert
   content that is objectionable, or misleading.

6.8.  Improves List Isolation

   Mailing lists are intended to be a closed group.  By using aliases,
   membership in the group is verified by the alias domain address.
   When a user leaves a group, he loses the ability to send messages to
   list members using their member alias, and list members lose the
   ability to contact him using his member alias address.  In most
   cases, the alias will be the only address that other members know.
   Actual addresses may be leaked in message headers, but they are not
   published explicitly in the From address.

6.9.  Permits portability

   Upon evidence satisfactory to the list owner, a subscriber can
   migrate to a new primary mailing account while preserving his member
   alias, and thereby retain his identity within the mailing list.

7.  IANA Considerations

   This memo includes no request to IANA.





Foster                    Expires 6 April 2022                  [Page 8]


Internet-Draft        DMARC Compliant Mailing Lists         October 2021


8.  Security Considerations

   *  Any form of aliasing introduces the possibility of identify
      misrepresentation or identity obfuscation.  Misrepresentation
      neecds to be controlled by the list operator during the enrollment
      process.  Obfuscation may or may not be acceptable, based on the
      policies and purposes of the mailing list.  A thorough discussion
      of the issues related to digital identity and enrollment can be
      found in NIST SP-800-63 [NIST800-63]

   *  The proposed design causes list messages to appear as if they are
      direct messages from the list domain, rather than forwarded
      messages that passed through the list domain.  As a result, the
      list domain will bear the reputation consequences, if any
      inappropriate messages are forwarded to the list.  The best
      defense against this risk is for the list domain to perform
      effective spam filtering.

   *  Subscribers within the list domain should be fully notified of the
      limitations of the aliasing strategy, and that their identity
      cannot be fully protected from other subscribers within the list
      domain.

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              DOI 10.17487/RFC2629, June 1999,
              <https://www.rfc-editor.org/info/rfc2629>.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,
              <https://www.rfc-editor.org/info/rfc3552>.

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



Foster                    Expires 6 April 2022                  [Page 9]


Internet-Draft        DMARC Compliant Mailing Lists         October 2021


   [RFC7960]  Martin, F., Ed., Lear, E., Ed., Draegen, T., Ed., Zwicky,
              E., Ed., and K. Andersen, Ed., "Interoperability Issues
              between Domain-based Message Authentication, Reporting,
              and Conformance (DMARC) and Indirect Email Flows",
              RFC 7960, DOI 10.17487/RFC7960, September 2016,
              <https://www.rfc-editor.org/info/rfc7960>.

10.  Informative References

   [NIST800-63]
              U.S. National Institute of Standards and Technology, "The
              four-volume SP 800-63 Digital Identity Guidelines document
              suite", 2017, <https://pages.nist.gov/800-63-3/>.

Author's Address

   Douglas Foster (editor)
   Self
   Virginia Beach, VA 23464
   United States of America

   Email: dougfoster.emailstandards@gmail.com





























Foster                    Expires 6 April 2022                 [Page 10]