Internet DRAFT - draft-fosterd-dmarc-spf-best-practices
draft-fosterd-dmarc-spf-best-practices
DMARC D.E. Foster, Ed.
Internet-Draft Self
Intended status: Informational 13 May 2023
Expires: 14 November 2023
Sender Authentication Best Practices
draft-fosterd-dmarc-spf-best-practices-00
Abstract
Sender Authentication contributes to the goal of detecting and
blocking maliciously impersonated email identifiers. Sender Policy
Framework (SPF) (RFC 7208) validates the RFC5321.MailFrom address,
and Domain-based Message Authentication, Reporting, and Conformance
(DMARC) (RFC 7489) validates the RFC5322.From header address. Both
techniques may produce a result other than PASS on a message that the
recipient considers acceptable and wanted. This document describes
best practices for integrating SPF and DMARC into an email filtering
strategy.
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 November 2023.
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
Foster Expires 14 November 2023 [Page 1]
Internet-Draft Sender Authentication BCP May 2023
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Email Filtering Reference Model . . . . . . . . . . . . . . . 3
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Privileged Mode Messages . . . . . . . . . . . . . . . . 4
2.3. Unwanted Messages . . . . . . . . . . . . . . . . . . . . 4
2.4. Non-privileged Messages with Content Filtering Fail . . . 4
2.5. Non-privileged Messages with Sender Authentication FAIL and
Content Filtering PASS . . . . . . . . . . . . . . . . . 5
2.6. Non-privileged Messages with Sender Authentiction PASS and
Content Filtering PASS . . . . . . . . . . . . . . . . . 5
2.7. Non-privileged Messages with Sender Authentiction Unknown
and Content Filtering PASS . . . . . . . . . . . . . . . 5
3. Alternate Authentication . . . . . . . . . . . . . . . . . . 6
4. DMARC Authentication Types and Confidence Levels . . . . . . 7
5. Forwarding Considerations . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
Sender Authentication contributes to the goal of detecting and
blocking maliciously impersonated email identifiers. Sender Policy
Framework (SPF) [RFC7208] validates the RFC5321.MailFrom address, and
Domain-based Message Authentication, Reporting, and Conformance
(DMARC) [RFC7489] validates the RFC5322.From header address. For
both techniques, a result of PASS indicates that the message is
judged to be free of impersonation, and therefore free of malicious
impersonation risk. Any message that does not produce PASS can
therefore be considered at risk of possible impersonation. From a
risk standpoint, the evaluator has little reason to distinguish
between results of NOPOLICY, PERMERROR, SOFTFAIL, or FAIL. However,
malicious impersonation is only one of many reasons that a message
does not produce PASS, and therefore malicious impersonation can only
be concluded after all other possibilities have been ruled out.
Foster Expires 14 November 2023 [Page 2]
Internet-Draft Sender Authentication BCP May 2023
2. Email Filtering Reference Model
2.1. Overview
A typical email filtering solution has two primary components, sender
filtering and content filtering. Sender filtering evaluates the
identifiers in a message to assign a reputation to the sender of the
message. Upon completion of sender filtering, the message has three
possible dispositons:
* Privileged: The message is from a highly trusted sender and is
exempted from some or all content filtering checks. Sender
Authenticaton PASS is required for Privileged mode to be granted
safely. Great harm could result if a malicious impersonation is
granted privileged mode, allowing it to bypass both sender filters
and content filters.
* Normal: The message sender is not rejected, but the messages must
pass all content filtering checks to be allowed.
* Unwanted: The message is blocked based on sender identity and
reputation alone. For purposes of this document, no distinction
is made whether the message is blocked with notification via an
SMTP reject result, blocked with notification via a Non-Delivery
Report, or silentlty discarded without notification.
A basic assumption is that unwanted and malicious email originates
from unwanted and malicious email senders. While content filtering
and sender authentication will flag or block single messages that are
suspicious, their greatest benefit accrues when they are used to
identify malicious message sending entities, so that all messages
from that sender can be blocked. Consider the situation where a
message is identified as malicious and blocked, but no follow-up
action is taken. When the attacker changes techniques, and a
subsequent attack succeeds, the system administrator will appear
negligent. This document assumes a continuous improvement process
with these characteristics:
* Content filtering or sender authentication identify a set of one
or more suspicious messages with common characteristics.
* The message set is reviewed in depth to assess whether the
messages are wanted or unwanted.
* If the message set is determined to be unwanted, the message
sender is identified and a local policy is implemented to block
messages from that sender.
Foster Expires 14 November 2023 [Page 3]
Internet-Draft Sender Authentication BCP May 2023
* If the message set is determined to be acceptable, but was flagged
as suspicious by content filtering, then a local policy is
implemented to give the message sender Privileged mode.
* If the message set is determined to be acceptable, but was flagged
as suspicious because of sender authentication failure, then a
local policy is implemented to provide alternate authentication
for that message set. Note that alternate authentication is
different from exemption. Exemption from sender authentication
provides exemption for both intented and impersonation messages.
Alternate authentication maintains a distinction between the
intended messages and their impersonators.
* When all other explanations have been exhausted, Sender
Authentication failure alone may provide evidence of malicious
intent. The difficulty is ruling out all other possible
explanations.
2.2. Privileged Mode Messages
Because any message may require Priviledged mode processing, any
message must be verifiable, using either SPF and DMARC or a local
policy which provides equivalent results. Local policy extends SPF
to define acceptable relationships between a verfied server
identifier and the RFC5321.MailFrom domain, and extends DMARC to
define acceptable relationships between a verified RFC5321.MailFrom
and the RFC5322.From domain. The supplemental authentication
techniques for this purpose are explained later in this document.
2.3. Unwanted Messages
Some messages will be categorized as unwanted because of previously
configured rules or trusted reference sources. These messages are
blocked, but content may be preserved for subsequent review or other
purposes.
2.4. Non-privileged Messages with Content Filtering Fail
Messages which fail Content Filtering are blocked. A subsequent
review is used to determine if content filtering needs to be updated,
if a sender block rule is needed for specific senders, or if a
Privilege Mode exemption is needed for trusted senders.
When a message set is determined to be unwanted, an analysis is
necessary to identify the identifiers which correctly represent the
source of the attack. In most cases, one or more identifiers can be
found which represent the source of the attack, and a single-
attribute block rule is created for each such identifier. In less
Foster Expires 14 November 2023 [Page 4]
Internet-Draft Sender Authentication BCP May 2023
common situations, a system manager may determine that an identifier
was fraudulent, but the underlying identifiers are not wholly
malicious. If this occurs, a multiple-attribute block rule is needed
to block the specific combination of identifiers. In either
configuration, verification of the identifiers is not necessary to
the purposes of a block rule.
2.5. Non-privileged Messages with Sender Authentication FAIL and
Content Filtering PASS
Messages which produce an authentication FAIL result will carry the
highest presumption of malicious impersonation, but exceptions will
occur. Content Filtering will provide additional insight into the
nature of the message, so disposition should be delayed until this
data has been collected. For messages that pass Content Filtering, a
sufficient defense is to quarantine these messages and prioritize
them for review and categorization. Confirmed malice will justify a
local policy to block all messages from the malicious source.
Acceptable messages will be granted a local policy to provide
alternate authentication.
2.6. Non-privileged Messages with Sender Authentiction PASS and Content
Filtering PASS
Messages which pass both Sender Authentication and Content Filtering
have no detected risk and are consequently released to the user.
User complaints could cause the sender to be reviewed and content
filtering rules to be enhanced.
2.7. Non-privileged Messages with Sender Authentiction Unknown and
Content Filtering PASS
Some messages will produce neither PASS nor FAIL, because of missing,
misconfigured, or non-enforcing domain owner policies. These
messages will be forwarded to content filtering, and may be blocked
on that basis. The remainder will be messages that have no detected
risk, but may have undetected impersonation. The evaluator must
decide whether to release such messages to the user or quarantine
them for prior review. The sheer volume of such messages will often
cause an organization to release such messages to the final
recipient, while retaining the option of after-the-fact review. The
risk of doing so is proportional to the effectiveness of the content
filtering system. As after-the-fact review identifies additional
message sources to be blocked and additional messages sources to be
granted local authentication policies, the volume of ambiguous
results will steadily decline. When the ambiguous volume is
sufficiently controlled, the evaluator can switch from after-the-fact
review to quarantine with prior review.
Foster Expires 14 November 2023 [Page 5]
Internet-Draft Sender Authentication BCP May 2023
3. Alternate Authentication
SPF and DMARC only provide results if the domain owner has published
a policy. The policy is generally considered actionable if the
policy returns a result of DMARC FAIL, or SPF FAIL without DMARC
PASS. Even then, the FAIL result can be misleading if the domain
owner's implementation is not consistent with its policy, or if the
message transit has caused the message to lose authentication. For
additional discussion of these issues, refer to Interoperability
Issues between Domain-based Message Authentication, Reporting, and
Conformance (DMARC) and Indirect Email Flows [RFC7960].
RFC 7208 and RFC 7489 provide no guidance for evaluators to cope with
incorrect, ambiguous, or No Policy results. Without exception
management, Sender Authentication dies as soon as an exception is
necessary. A poorly designed exception process may enable the very
impersonations that Sender Authentication is intended to prevent. To
handle exceptions appropriately, and to ensure that any acceptable
message can be configured as authenticated, additional authentication
techniques are needed:
* DMARC using a local alignment policy: When a DMARC policy is not
provided, DMARC-equivalent verification can be applied using an
alignment rule configured by local policy to produce an equivalent
PASS or FAIL result.
* DKIM with alternate allignment: When a verified DKIM [RFC6376]
signature is available, and the From domain is not DMARC-aligned,
but the From address is determined to have an acceptable
relationship to the DKIM domain, the message is considered
equivalent to DMARC PASS. SPF PASS is optional when the From
address is authenticated by a DKIM signature.
* SPF with alternate alignment: When the RFC5321.MailFrom domain is
verified with SPF PASS, and the From domain is not DMARC-aligned,
but is determined to have an acceptable relationship to the
MailFrom domain, the message is considered equivalent to DMARC
PASS.
* SPF with alternate server: When a message does not produce SPF
PASS, but the RFC5321.MailFrom domain is determined to have an
acceptable relationship to the server organization, equivalence to
SPF PASS can be established using the Source IP, a forward-
confirmed HELO name that represents the server organization, or a
forward-confirmed Reverse DNS name which represents the server
organization. The SPF-equivalent PASS result can then be used to
test the RFC5321.From domain for DMARC-equivalent PASS.
Foster Expires 14 November 2023 [Page 6]
Internet-Draft Sender Authentication BCP May 2023
4. DMARC Authentication Types and Confidence Levels
DMARC combines eight different authentiction types into a single
result, but the eight types do not provide equal confidence.
Evaluators should be aware of the possibility of false PASS, and
consider that risk when developing local policies, especially local
alignment policies.
DKIM and SPF are the two underlying authentication techniques for
DMARC, and within each technique there are four possible alignment
methods: Self authenticates self, parent authenticates child, child
authenticates parent, and sibling authenticates sibling,
When a message is sent from a multi-tenant server, SPF assumes that
the server owner has administrative controls which prevent clients
from impersonating each other, or that all clients are well behaved.
DKIM, by contrast, has the much simpler expectation that the server
owner is able to ensure that each client's private key data is kept
private to themselves, out of reach from other clients in the same
environment. Consequently, DKIM PASS always conveys a higher level
of confidence than SPF PASS. Of course, a DKIM signature also
ensures that authentication is preserved during forwarding (when done
without content changes), so DKIM also provides confidence to a
broader range of evaluators. In short, domain owners who wish to
promote maximum trust by evaluators should ensure that all of their
messages have verifiable DKIM signatures.
Similarly, the different types of alignment provide different levels
of confidence. When the authenticating domain exactly matches the
authenticated domain, trust in the result is maximized. The three
varieties of relaxed alignment depend on correctly identifying the
organizational domain. The Public Suffix List from publicsuffix.org
is the reference used by most organizations, but it is not an
authoritative source, is modified on a continuing basis, is developed
for cross-site-scripting defenses rather than email defensies, and
has detectable errors and omisssions. While the frequency of errors
may be low, the impact of an error may be significant. If the PSL
lands too low, the evaluator may not see a DMARC policy at all, or
may see the wrong policy. If the PSL lands too high, the evaluator
may authenticate sibling organizations as if they were sibling
domains within a single organization. The impact of a PSL error
varies with the type of authentication:
* Parent-authenticates-child is the most trustworthy form of relaxed
alignment. DNS is managed hierarchically, so a parent domain has
unlimited control over a child domain if they choose to seize such
control. Most organizations also operate on hierarchical control,
so the DNS structure is consistent with the real world that it is
Foster Expires 14 November 2023 [Page 7]
Internet-Draft Sender Authentication BCP May 2023
modelling. The risk of a registry domain impersonating a
registered client is assumed to be inherently low, but is within
the rights of a parent domain. Consequently, a parent-
authenticates-child relationship carries a high level of
confidence, nearly equivalent to strict alignment.
* Child-authenticates-parent is a little less intuitive, because it
is not consistent with the heirarchical way that organizations
operate. Curiously, it is the most commonly observed form of
relaxed alignment. An evaluator can assume that if a child domain
is improperly used to impersonate a parent domain, the response
from the parent domain will be swift and harsh. Consequently, a
child-authenticates-parent relationship retains a significant
degree of confidence.
* Sibling-authenticates-sibling does not have an intuitive
relationship to the control mechanisms of hierarchical
organizations. More importantly, sibling authentication is
vulnerable to PSL errors used for malicious purposes.
Consequently, it is the least trustworthy from of relaxed
authentication.
Domain owners who seek to maximize evaluator trust should utilize
those authentication types which provide the highest confidence to
evaluators. When configuring local authentication policies,
evaluators have the option of applying any of four confidence levels,
to obtain their desired balance between maximizing policy coverage
and maximizing confidence in a PASS result.
5. Forwarding Considerations
Forwarding creates significant challengers for the evaluator seeking
to eliminate impersonation. The evaluator needs to assess the
reputation of both the originator and the forwarder, but in most
cases, the greater concern applies to the originator. The process of
forwarding:
* obscures the originating organization behind the forwarding
organization,
* will either invalidate SPF PASS on the original RFC5321.MailFrom
domain, or replace it completely to obtain SPF PASS on the
forwarder domain,
* may involve content changes that invalidate DKIM signatures, and
* may alter the RFC5322.From header to evade DMARC problems on
altered messages.
Foster Expires 14 November 2023 [Page 8]
Internet-Draft Sender Authentication BCP May 2023
Consequently, an ideal evaluation process needs to include:
* identifying that one or more forwarding operations occurred,
* verifying through administrative measures that the recipient wants
the forwarded stream,
* deciding how much filtering trust can be delegated to the
forwarder,
* inferring, as much as possible, the identity of the originating
server organization, RFC5321.MailFrom address, and RFC5322.From
address,
* applying a reputation based on all of the above, and
* applying a disposition based on the reputation and the results of
content filtering.
Forwarding may be easier to detect in aggregate than on single
messages, because a forwarding configuration will produce a stream of
messages from a single server organization, on behalf of a wide
variety of RFC5322.From domains. Within a single message, these data
sources may be available to help detect forwarding:
* An ARC Chain can be parsed to extract prior identifiers and their
prior verification state.
* Received headers containing a "for user@domain" clause may reveal
the original destination address. An MX lookup on that domain may
permit determination of the Received entry which indicates arrival
at the forwarding organization's MX server.
* The sequence of organization changes and private knowlehdge can be
used to identify organization roles: submitting agent domain,
mailstore domain, outbound gateway domain, or forwarding domain.
Organizational changes are inferred when the Received header chain
transits between public and private IP addresses, and when two
adjacent public IP addresses are identified as belonging to
different server domains.
* An RFC5322.To address list which does not contain the
RFC5321.RcptTo address can indicate many things, one of which is a
forwarding operation.
Foster Expires 14 November 2023 [Page 9]
Internet-Draft Sender Authentication BCP May 2023
* An RFC5321.MailFrom address that is encoded using the Sender
Rewriting Scheme (SRS) can be decoded to reveal the prior
RFC5321.MailFrom address or addresses. However, SRS encoding is
also used by some servers upon origination, to detect invalid
bounce messages.
* Forwarding without RFC5321.MailFrom rewrite is one of many reasons
that a message will fail to produce SPF PASS.
While these are potentially useful clues, this document does not
attempt to provide an algorithm for optimal interpretation of these
clues. Evaluators must consider that Received headers may be forged
and ARC Sets may mislead. Consequently, header parsing is most
reliable when it is used to identify messages that are unwanted
because of detected identifiers with an unacceptable reputation.
Evaluators who wish to choose to accept forwarded mail, but cannot
perform detailed header parsing, will need to authenticate based on
the forwarder identity alone. For messages forwarded without
RFC5321.MailFrom rewrite, this requires a local policy to provide
alternate authentication for the RFC5321.MailFrom address. The
policy would need to specify that any MailFrom domain is acceptable
as long as the forwarding server identity matches the expected Source
IP or the server host domain matches the expected domain name and is
forward confirmed. For messages forwarded with RFC5321.MailFrom
rewrite to provide SPF PASS based on the forwarder's domain, the
local policy would need to specify that all RFC5322.From domains are
acceptable as long as the RFC5321.MailFrom domain has the expected
value and is confirmed by SPF PASS or a local policy equivalent. In
either case, the evaluator is implicitly assuming that either the
forwarder will intercept and block malicious impersonation, or that
the evaluator's content filtering will be strong enough to intercept
and block any malicious impersonation in the forwarded stream.
Forwarders should consider that many evaluators will not attempt to
navigate the complexity of originator detection. Instead, any
unacceptable messages will be assigned to the reputation of the
forwarder, which could lead to obstruction of messages unrelated to
the forwarded stream. Consequently, forwarders should apply the same
rigorous filtering to forwarded messages as they use to protect their
own domain.
Additionally, forwarders should be aware of the impact that content-
altering spam filters will have on forwarded mail. An increasing
number of spam filters add disclaimers to distinguish external mail
from internal mail, or rewrite embedded links to provide click-time
protection. Any such change will invalidate the originator's DKIM
signatures, causing an authentication problem if the message is
Foster Expires 14 November 2023 [Page 10]
Internet-Draft Sender Authentication BCP May 2023
forwarded in its altered state. Consequently, organizations that use
content-altering spam filters should not forward mail, and
organizations that routinely forward mail should not use content-
altering featues of their spam filter.
6. IANA Considerations
This memo includes no request to IANA.
7. Security Considerations
The goal of sender authentication is to separate well-identified
messages from potentially-impersonated messages. Successful sender
authentication is a necessary pre-requisite to privileged-mode
handling of a document, but it is not a reason to grant that
privilege. Sender authentication simply ensures that any reputation
information, obtianed by other methods, can be applied correctly.
Evaluators must remember that both sender infrastructure and sender
reputation can change over time and therefore they must remain
vigilant. Previously trusted sources may become compromised or even
retired and reassigned to other, less trustworthy, uses. Similarly,
a previously untrusted source may have earned that designation
because of an infection which has been subsequntly corrected. Coping
with these sources of variability is outside the scope of this
document.
Becuase of the additional risk associated with sibling relationships,
evaluators may wish to treat authentication based on sibling
alignment more carefully than other forms of relaxed alignment.
8. References
8.1. Normative 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>.
Foster Expires 14 November 2023 [Page 11]
Internet-Draft Sender Authentication BCP May 2023
[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>.
8.2. Informative References
[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>.
Author's Address
Douglas Foster (editor)
Self
Virginia Beach, VA 23464
United States of America
Email: dougfoster.emailstandards@gmail.com
Foster Expires 14 November 2023 [Page 12]
