Internet DRAFT - draft-fosterd-dmarc-compliant-mailing-lists
draft-fosterd-dmarc-compliant-mailing-lists
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]
