Sender ID: Authenticating E-Mail
draft-lyon-senderid-core-01
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4406.
|
|
|---|---|---|---|
| Authors | Meng Weng Wong , Jim Lyon | ||
| Last updated | 2020-02-12 (Latest revision 2005-05-19) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Experimental | ||
| Formats | |||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 4406 (Historic) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Ted Hardie | ||
| Send notices to | (None) |
draft-lyon-senderid-core-01
Internet Draft J. Lyon
Category: Experimental Microsoft Corp
Document: draft-lyon-senderid-core-01.txt M. Wong
pobox.com
May 2005
Sender ID: Authenticating E-Mail
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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 a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
Internet mail suffers from the fact that much unwanted mail is sent
using spoofed addresses -- "spoofed" in this case means the address
is used without the permission of the domain owner. This document
describes a family of tests by which SMTP servers can determine
whether an e-mail address in a received message was used with the
permission of the owner of the domain contained in that e-mail
address.
Lyon, Wong Experimental [Page 1]
quot;MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
All the mobility-related terms used in this document are to be
interpreted as defined in the Proxy Mobile IPv6 specifications
[RFC5213] and [RFC5844]. Additionally, this document uses the
following abbreviations:
Network Access Server (NAS):
A function that provides authorization services for a device/user
access to the network as defined in [RFC2865]. This document
makes an assumption that the NAS function is co-located with the
Xia, et al. Standards Track [Page 4]
RFC 6572 RADIUS PMIPv6 June 2012
MAG. In scenarios where the NAS function and MAG are decoupled,
the messaging interface needed between them for the operation of
PMIP6 is beyond the scope of this document.
Home AAA (HAAA):
An Authentication, Authorization, and Accounting (AAA) server
located in the MN's home network. This sever has access to the
mobile node's policy profiles.
Visited AAA (VAAA):
An Authentication, Authorization, and Accounting (AAA) server
located in the MN's visited network. The VAAA server takes the
role of a proxy-server, forwarding the received AAA service
request to the HAAA server in the mobile node's home network and
relaying the response to the requesting node, after applying any
local access network policies.
Local AAA (LAAA):
An Authentication, Authorization, and Accounting proxy located in
the local network. In a roaming case, the local AAAA has the
visited AAA role.
3. Solution Overview
This document defines the RADIUS-based AAA interactions with the two
mobility management elements in the Proxy Mobile IPv6 domain.
o Interactions between a MAG and a RADIUS-based AAA server
o Interactions between a LMA and a RADIUS-based AAA server
The mobile node's policy profile [RFC5213] is present in a policy
store and is needed by the PMIPv6 mobility management elements for
authorizing the mobile node for mobility management service and for
obtaining various service-related parameters. This policy store
could be locally co-located with the mobility management agents
enabling direct local access or could be available from a AAA server
through a RADIUS-based AAA interface.
When a mobile node attaches to an access network, the NAS on that
access network may activate the network access authentication
procedure. The choice of the authentication mechanism is specific to
the access network deployment; however, it is typically based on the
Extensible Authentication Protocol (EAP) [RFC3748]. The NAS performs
the network access authentication and queries the HAAA using AAA
Xia, et al. Standards Track [Page 5]
RFC 6572 RADIUS PMIPv6 June 2012
protocol, such as RADIUS. If the network access authentication
succeeds, the MN's policy profile is obtained as part of the RADIUS
message exchange with the AAA server.
The mobile node may be an IPv4-only node, IPv6-only node, or a dual-
stack (IPv4/v6) node. Based on the policy specified in the policy
profile, the network access authentication procedure SHOULD provide
the unambiguous indication of the type of address(es) to be assigned
for the MN in the network and with all other service-related and
policy parameters relevant to the mobility service.
After the successful network access authentication and obtaining the
mobile node's policy profile, the MAG sends a Proxy Binding Update
(PBU) to the LMA. Upon receiving the PBU, the LMA interacts with the
HAAA to obtain the mobile node's policy profile, which is required
for authorizing and activating mobility service.
This document adds support for three distinct PMIPv6 mobility use
cases, taking into account the administrative domains to which the
MAG and the LMA belong. The following are the three relevant
deployment models.
1. the MAG and LMA are both in the home network,
2. the MAG and LMA are both in the visited network,
3. the MAG is in the visited network while the LMA is in the home
network.
Figure 1 shows participating network entities for the PMIPv6 mobility
session, which is located in the home network. The MAG and LMA
interact only with the HAAA.
Xia, et al. Standards Track [Page 6]
RFC 6572 RADIUS PMIPv6 June 2012
+--------+
| HAAA & | RADIUS +-----+
| Policy |<-------->| LMA |
| Profile| +-----+
+--------+ | <--- LMA-Address
^ |
| // \\
+---|------------- //---\\----------------+
( | IPv4/IPv6 // \\ )
( | Network // \\ )
+---|-----------//---------\\-------------+
| // \\
RADIUS // <- Tunnel1 \\ <- Tunnel2
| // \\
| |- MAG1-Address |- MAG2-Address
| +----+ +----+
+---->|MAG1| |MAG2|
+----+ +----+
| |
| |
MN1 MN2
Figure 1: The MAG and LMA Are Both in the Home Network
Figure 2 shows both the LMA and MAG are in the visited network. The
MAG and LMA exchange signaling with the HAAA through the VAAA, which
acts as a Proxy. The visited network may append additional
information to the HAAA replies in order to reflect the local policy.
Xia, et al. Standards Track [Page 7]
RFC 6572 RADIUS PMIPv6 June 2012
+---------------+
| HAAA &Sender ID: Authenticating E-Mail May 2005
Table of Contents
1. Introduction...................................................3
2. Problem Statement..............................................3
3. SPF Records....................................................4
3.1 Version and Scope..........................................4
3.2 Multiple Records...........................................5
3.3 Positional Modifiers.......................................4
3.4 Compatibility..............................................7
4. Decision Model.................................................7
4.1 Arguments..................................................8
4.2 Results....................................................8
4.3 Record Lookup..............................................8
4.4 Record Selection...........................................8
5. Actions Based on the Decision..................................9
5.1 Neutral, None, SoftFail or PermError.......................9
5.2 Pass.......................................................9
5.3 Fail......................................................10
5.4 TempError.................................................10
6. Security Considerations.......................................11
6.1 DNS Attacks...............................................11
6.2 TCP Attacks...............................................11
6.3 Forged Sender Attacks.....................................11
6.4 Address Space Hijacking...................................12
6.5 Malicious DNS attacks on third-parties....................12
7. Implementation Guidance.......................................13
7.1 Simple E-mailers..........................................13
7.2 E-Mail Forwarders.........................................13
7.3 Mailing List Servers......................................14
7.4 Third-Party Mailers.......................................14
7.5 MUA Implementers..........................................15
8. IANA Considerations...........................................15
9. Acknowledgements..............................................16
10. References...................................................16
10.1 Normative References.....................................16
10.2 Informative References...................................16
11. Authors' Addresses...........................................17
Conventions used in this document
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 [RFC2119].
Lyon, Wong Experimental [Page 2]
Sender ID: Authenticating E-Mail May 2005
1. Introduction
Today, a huge majority of unwanted e-mail contains headers that lie
about the origin of the mail. This is true of most spam and
substantially all of the virus e-mail that is sent.
This document describes a mechanism such that receiving MTAs, MDAs
and/or MUAs can recognize mail in the above category and take
appropriate action. For example, an MTA might refuse to accept a
message, an MDA might discard a message rather than placing it into a
mailbox, and an MUA might render that message in some distinctive
fashion.
In order to avoid further fragmentation of the Internet e-mail
system, it is desirable that the Internet community as a whole come
to a consensus as to what mail senders should do to make their mail
appear non-spoofed, and how mail receivers should determine whether
mail is spoofed. On the other hand, it is not necessary to reach a
consensus regarding the actions that various parties take once a
message has been determined to be spoofed. This can be done one
unilaterally -- agent might decide to discard a spoofed message while
another decides to add a disclaimer.
This document defines a pair of closely-related tests. One validates
a message's Purported Responsible Address (PRA) as defined in [PRA].
The other validates a message's Reverse-Path (also known as MAIL-FROM
address) as defined in [SPF].
An e-mail sender complying with this specification SHOULD publish
information for both tests, and SHOULD arrange that any mail that is
sent will pass both tests. An e-mail receiver complying with this
specification SHOULD perform at least one of these tests.
2. Problem Statement
Briefly stated, the mechanisms of this document allow one to answer
the following question:
When a message is transferred via SMTP between two unrelated
parties, does the SMTP client host have permission to send mail
on behalf of a mailbox referenced by the message?
As seen from the question, this mechanism applies to unrelated
parties: it is useful at the point where a message passes across the
Internet from one organization to another. It is beyond the scope of
this document to describe authentication mechanisms that can be
deployed within an organization.
Lyon, Wong Experimental [Page 3]
Sender ID: Authenticating E-Mail May 2005
The PRA version of the test seeks to authenticate the mailbox
associated with the most recent introduction of a message into the
mail delivery system. In simple cases, this is who the mail is from.
However, in the case of a third-party mailer, a forwarder or a
mailing list server, the address being authenticated is that of the
third party, the forwarder or the mailing list.
On the other hand, the MAIL-FROM version of the test seeks to
authenticate the mailbox that would receive Delivery Status
Notifications (DSNs, or bounces) for the message. In simple cases,
this too is who the mail is from. However, third-party mailers,
forwarders and mailing list servers MUST specify an address under
their control, and SHOULD arrange that DSNs received at this address
are forwarded to the original bounce address.
In both cases, the domain associated with an e-mail address is what
is authenticated; no attempt is made to authenticate the local-part.
A domain owner gets to determine which SMTP clients speak on behalf
of addresses within the domain; a responsible domain owner should not
authorize SMTP clients that will lie about local parts.
In the long run, once the domain of the sender is authenticated, it
will be possible to use that domain as part of a mechanism to
determine the likelihood that a given message is spam, using, for
example, reputation and accreditation services. (These services are
not the subject of the present mechanism, but it should enable them.)
3. SPF 2.0 Records
Domains declare which hosts are and are not authorized to transmit
e-mail messages on their behalf by publishing Sender Policy Framework
records in the Domain Name System. [SPF] defines a format for these
records identified by the version prefix "v=spf1". This section
defines an amended format, identified by the version prefix
"spf2.0", that allows sending domains to explicitly specify how their
records should be interpreted, and provides for additional
extensibility. Sending domains MAY publish either or both formats.
Since the two formats are identical in most respects, the following
sub-sections define the "spf2.0& |
+----------| Policy Profile|
| +---------------+
|
+---------+
|[VL]AAA &| RADIUS +-----+
| Policy |<------->| LMA |
| Profile | +-----+
+---------+ | <--- LMA-Address
^ // \\
+---|------------- //---\\----------------+
( | IPv4/IPv6 // \\ )
( | Network // \\ )
+---|-----------//---------\\-------------+
| // \\
RADIUS // <- Tunnel1 \\ <- Tunnel2
| // \\
| |- MAG1-Address |- MAG2-Address
| +----+ +----+
+---->|MAG1| |MAG2|
+----+ +----+
| |
MN1 MN2
Figure 2: The MAG and LMA Are Both in the Visited/Local Network
Figure 3 illustrates a topology where the MAG resides in the visited
network while the associated LMA is in MN's home network. Any
message between the MAG and the HAAA passes through the VAAA, which
acts as a Proxy. During the network authentication, the visited
network's specific policy may also be propagated from the VAAA to the
MAG. The LMA has a direct access to the HAAA.
Xia, et al. Standards Track [Page 8]
RFC 6572 RADIUS PMIPv6 June 2012
+---------------+
| HAAA & |
+----------| Policy Profile|
| +---------------+
| |
| RADIUS
+---------+ |
|[VL]AAA &| +-----+
| Policy | | LMA |
| Profile | +-----+
+---------+ | <--- LMA-Address
^ // \\
+---|------------- //---\\----------------+
( | IPv4/IPv6 // \\ )
( | Network // \\ )
+---|-----------//---------\\-------------+
| // \\
RADIUS // <- Tunnel1 \\ <- Tunnel2
| // \\
| |- MAG1-Address |- MAG2-Address
| +----+ +----+
+---->|MAG1| |MAG2|
+----+ +----+
| |
MN1 MN2
Figure 3: Visited MAG and Home LMA Topology
4. Attribute Definitions
4.1. MIP6-Feature-Vector
Diameter [RFC3588] reserves AVP Code space 1-255 as RADIUS attribute
compatibility space. The MIP6-Feature-Vector attribute (Type value
124) defined in [RFC5447] is of type OctetString and contains a
64-bit flags field of supported mobility capabilities. This document
reserves two new capability bits according to the rules in [RFC5447],
and reuses the PMIPv6 capability bits defined by [RFC5779]. The
following capability flag bits are used or defined in this document:
PMIP6_SUPPORTED (0x0000010000000000)
This capability bit is used as defined in [RFC5779].
IP4_HOA_SUPPORTED (0x0000020000000000)
This capability bit is used as defined in [RFC5779]. Assignment
of the IPv4-HoA (Home Address) is defined by [RFC5844].
Xia, et al. Standards Track [Page 9]
RFC 6572 RADIUS PMIPv6 June 2012
LOCAL_MAG_ROUTING_SUPPORTED (0x0000040000000000)
This capability bit is used as defined in [RFC5779].
IP4_TRANSPORT_SUPPORTED (0x0000800000000000)
This capability bit is used for negotiation of the IPv4 transport
support between the MAG and AAA. When the MAG sets this flag bit
in the MIP6-Feature-Vector, it indicates the ability of the MAG to
provide IPv4 transport (i.e., IPv4-based encapsulation) for
carrying IP traffic between the MAG and the LMA. If this flag bit
is unset in the returned MIP6-Feature-Vector attribute, the AAA
does not authorize the use of IPv4 transport on the MAG-to-LMA
tunnel.
IP4_HOA_ONLY_SUPPORTED (0x0001000000000000)
This capability bit is used for determination of the authorized
PMIPv6 mobility mode. When this bit is set by the AAA, it
indicates PMIPv6 mobility with IPv4 support has only been
authorized for the MN. As a result, the RADIUS Access-Accept
SHOULD NOT carry the IPv6 Home Network Prefix (IPv6 HNP). When
this bit is set, the PMIP6_SUPPORTED flag MUST also be set and the
IP4_HOA_SUPPORTED flag MUST NOT be set.
To summarize the use of the MIP6-Feature-Vector the following
capability bit combination settings mean:
PMIP6-SUPPORTED bit set - only IPv6 mobility is supported and
authorized.
PMIP6-SUPPORTED and IP4-ONLY-HOA-SUPPORTED bits set - only IPv4
mobility is supported and authorized.
PMIP6-SUPPORTED and IP4-HOA-SUPPORTED bits set - both IPv6 and
IPv4 mobility are supported and authorized.
The MIP6-Feature-Vector attribute is also used on the LMA to the
RADIUS AAA interface. This capability announcement attribute enables
direct capability negotiation between the LMA and the AAA. The
capabilities that are announced by both parties in the MIP6-Feature-
Vector are known to be mutually supported. The LMA may use this
mechanism during authorization of the received PBU against the AAA to
check individual PMIPv6 feature permissions for a particular MN.
If the RADIUS Access-Accept contains a contradicting combination of
the capability flag bits such as both the IP4_HOA_ONLY_SUPPORTED and
the IP4_HOA_SUPPORTED flags being set, then the RADIUS client MUST
Xia, et al. Standards Track [Page 10]
RFC 6572 RADIUS PMIPv6 June 2012
treat the Access-Accept as an Access-Reject and SHOULD log the event.
Similarly, if the RADIUS Access-Request contains a contradicting
combination of the capability flag bits, then the RADIUS server MUST
reply with an Access-Reject message and SHOULD log the event.
4.2. Mobile-Node-Identifier
The Mobile-Node-Identifier attribute (Type value 145) is of type
String and contains the mobile node identifier (MN-Identifier), see
[RFC5213], in a form of a Network Access Identifier (NAI) [RFC4282].
This identifier and the identifier used for access authentication may
be different; however, there needs to be a mapping between the two
identities as specified in Section 6.6 of [RFC5213]. This attribute
is used on the interface between the MAG and the AAA server. The
Mobile-Node-Identifier attribute is designed for deployments where
the identity used during network access authentication and the
identity used for mobility management is decoupled. It may also be
the case where the MAG does not have means to find out the MN
identity that could be used in subsequent PBU and Proxy Binding
Acknowledgement (PBA) exchanges (e.g., due to identity hiding during
the network access authentication) or when the HAAA wants to assign
periodically changing identities to the MN.
The Mobile-Node-Identifier attribute MAY be returned by the HAAA in
the RADIUS Access-Accept message that completes a successful
authentication and authorization exchange between the MAG and the
HAAA. The MAG MUST use the received MN-Identifier.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Mobile Node Identifier... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Mobile-Node-Identifier 145.
Length:
In octets, including Type and Length fields (>= 3).
Mobile Node Identifier:
This field is of type String and contains the MN-Identifier
of the MN to be used in the PBU/PBA exchange.
Xia, et al. Standards Track [Page 11]
RFC 6572 RADIUS PMIPv6 June 2012
4.3. Service-Selection
The Service-Selection attribute (Type value 146) is of type UTF-8
text and contains the name of the service or the external network
with which the mobility service for the particular MN SHOULD be
associated [RFC5149]. The identifier MUST be unique within the
PMIPv6 Domain when normalized using the selected normalization form
[UNF] for the particular PMIPv6 Domain deployment. For instance,
[RFC5149] uses the Normalization Form KC (NFKC).
The MAG MUST include the Service-Selection attribute in the Access-
Request sent to the AAA if the information was acquired, e.g., by
operator-specific configuration. The AAA MAY include the Service-
Selection attribute in the Access-Accept response message to the MAG
even if it was not included in the Access-Request as a means of
indicating the MN's default service.
The Service Selection mobility option defined in [RFC5149] can be
used in PBU/PBA messages between the MAG and LMA. On the LMA-to-AAA
interface, the LMA MAY populate the Service-Selection attribute in
the Access-Request message using the service information found in the
received PBU, if such a mobility option were included. The Service-
Selection identifier should be used to assist the PBU authorization,
the assignment of the MN-HNP, and the IPv4-MN-HoA as described in
[RFC5149] and [RFC5779].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Service Identifier... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
Service-Selection 146.
Length:
In octets, including Type and Length fields (>= 3).
Text:
This field is of type UTF-8 text and contains the Service
Identifier with which the MN is associated.
4.4. PMIP6-Home-LMA-IPv6-Address
The PMIP6-Home-LMA-IPv6-Address attribute (Type value 147) is of type
IPv6 address and is used to deliver the IPv6 address of the LMA
located in the home network.
Xia, et al. Standards Track [Page 12]
quot; format relative to [SPF].
3.1 Version and Scope
Under Sender ID, receiving domains may perform a check of either the
PRA identity or the MAIL-FROM identity. Sending domains therefore
require a method for declaring whether their published list of
authorized outbound e-mail servers can be used for the PRA check,
the MAIL-FROM check or both.
Lyon, Wong Experimental [Page 4]
Sender ID: Authenticating E-Mail May 2005
This section replaces section 4.5 of [SPF] and adds the concept of
SPF record scopes.
SPF records begin with a version identifier and may also include a
scope:
record = version terms *SP
version = "v=spf1" | ( "spf2." ver-minor scope)
ver-minor = 1*DIGIT
scope = "/" scope-id *( "," scope-id )
scope-id = "mfrom" / "pra" / name
For example, the SPF record:
spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all
defines an SPF record that can be used for either MAIL FROM or PRA
checks.
This document only defines the existence of two scopes: "mfrom" and
"pra". The details of these two scopes are defined in other
documents: "mfrom" is defined in [SPF], "pra" is defined in [PRA].
Other scopes may be defined by future documents only. There is no
registry for scopes. A scope definition must define what it
identifies as the sending mailbox for a message, how to extract that
information from a message, how to determine the initial arguments
for the check_host() function, and what the compliant responses to
the result are. This ensures that domains with published records and
mail receiver agree on the semantics of the scope.
A compliant domain SHOULD publish authorizations for every defined
scope.
3.1.1 Minor Version
All published records that use the "spf2" version identifier MUST
start with "spf2.0". This document only specifies records with a
minor version of "0".
Future versions of this document may define other minor versions to
be used.
3.2 Multiple Records
A domain MAY publish multiple SPF 2.0 records, provided that each
scope appears in at most one SPF 2.0 record. In addition, a domain
MAY also publish an SPF record that uses the "v=spf1" version
identifier defined in [SPF]. The selection rules in Section 4.4
define the precedence of these records.
Lyon, Wong Experimental [Page 5]
Sender ID: Authenticating E-Mail May 2005
3.3 Positional Modifiers
This section replaces section 4.6.3 of [SPF] and adds the concept of
positional modifiers.
Modifiers are key/value pairs that affect the evaluation of the
check_host() function.
Modifiers are either global or positional:
Global modifiers MAY appear anywhere in the record, but SHOULD
appear at the end, after all mechanisms and positional modifiers.
Positional modifiers apply only to the mechanism they follow. It
is a syntax error for a positional modifier to appear before the
first mechanism.
Modifiers of either type are also either singular or multiple:
Singular modifiers may appear only once in the record if they are
global, or once after each mechanism if they are positional.
Multiple modifiers may appear multiple times in the record if they
are global or multiple times after each mechanism if they are
positional.
A modifier is not allowed to be defined as both global and
positional.
The modifiers "redirect" and "exp" described in section 5 of [SPF]
are global and singular.
Ordering of modifiers does not matter, except:
1) positional modifiers must appear after the mechanism they
affect and before any subsequent mechanisms.
and 2) when a multiple modifier appears more than one time, the
ordering of the appearances may be significant to the
modifier.
Other than these constraints, implementations MUST treat different
orders of modifiers the same. An intended side effect of these rules
is modifiers cannot be defined that modify other modifiers.
These rules allow an implementation to correctly pre-parse a record.
Furthermore, they are crafted to allow the parsing algorithm to be
stable, even when new modifiers are introduced.
Modifiers which are unrecognized MUST be ignored. This allows older
implementations to handle records with modifiers that were defined
after they were written.
Lyon, Wong Experimental [Page 6]
Sender ID: Authenticating E-Mail May 2005
3.4 Compatibility
Domain administrators complying with this specification are required
to publish information in DNS regarding their authorized outbound
e-mail servers. [SPF] describes a format for this information
identified by the version prefix "v=spf1". Many domains have
published information in DNS using this format. In order to
provide compatibility for these domains, Sender ID implementations
SHOULD interpret the version prefix "v=spf1" as equivalent to
"spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists.
Administrators who have already published "v=spf1" records SHOULD
review these records to determine whether they are also valid for use
with PRA checks. If the information in a "v=spf1" record is not
correct for a PRA check, administrators SHOULD publish either an
"spf2.0/pra" record with correct information, or an "spf2.0/pra ?all"
record indicating that the result of a PRA check is explicitly
inconclusive.
4. Decision Model
Sender ID enables receiving e-mail systems to answer the question:
Given an e-mail message, and given an IP address from which it has
been (or will be) received, is the SMTP client at that IP address
authorized to send that e-mail message?
This question will usually be asked by an SMTP server as part of
deciding whether to accept an incoming mail message. However, this
question could also be asked later by a different party. An MUA, for
example, could use the result of this question to determine how to
file or present a message.
There are three steps to answering this question:
(1) From an e-mail message, extract the address to verify. The PRA
variant of this test does so as specified in [PRA], or
alternatively, using the submitter address as specified in
[Submitter]. The MAIL FROM variant of this test does so as
specified in [SPF].
(2) Extract the domain part of the address determined in step (1).
(3) Call the check_host() function defined in [SPF] and modified by
the following sub-sections.
Lyon, Wong Experimental [Page 7]
Sender ID: Authenticating E-Mail May 2005
If the Sender ID check is being performed by an MTA as part of
receiving an e-mail message, and it cannot determine an address in
step (1) above (because the message or address is malformed), then
the message SHOULD be rejected with error "550 5.7.1 Missing
Purported Responsible Address" or error "550 5.7.1 Missing Reverse-
Path address".
4.1 Arguments
Sender ID modifies the check_host() function by the addition of a
scope parameter. Thus, for Sender ID the check_host() function is
called passing the following parameters:
a. A scope of "pra" (for the PRA variant of the test), or
"mfrom" (for the MAIL FROM variant of the test).
b. The IP address (either IPv4 or IPv6) from which the message
is being or has been received.
c. The domain from step (2) above.
d. The address from step (1) above.
4.2 Results
The result of the check_host() function is one of the values
"Neutral", "Pass", "Fail", "SoftFail", "None", "TempError" or
"PermError". Section 5 describes how these results are used by MTAs
receiving messages. This specification imposes no requirements on
parties performing this test in other environments.
4.3 Record Lookup
SPF records are looked up in DNS in accordance with section 4.4 of
[SPF}.
When performing the PRA version of the test, if the DNS query returns
"non-existent domain" (RCODE 3), then check_host() exits immediately
with the result "Fail".
4.4 Record Selection
This section replaces the record selection steps described in section
4.5 of [SPF].
Starting with the set of records that were returned by the lookup,
record selection proceeds in these steps:
1. If any records of type SPF are in the set, then all records of
type TXT are discarded.
Lyon, Wong Experimental [Page 8]
Sender ID: Authenticating E-Mail May 2005
2. Records that do not begin with proper version and scope sections
are discarded. The version section for "spf2" records contains a
ver-minor field that is for backward compatible future
extensions. This field must be well-formed for a record to be
retained, but is otherwise ignored.
3. Records that use the "spf2" version identifier and do not have a
scope-id that matches <scope> are discarded. Note that this is a
complete string match on the scope-id tokens: If <scope> is "pra",
then the record starting "spf2.0/mfrom,prattle,fubar" would be
discarded, but a record starting "spf2.0/mfrom,pra,fubar" would be
retained.
4. If the lookup returned two records, one containing the "v=spf1"
version identifier and the other containing the "spf2"
version identifier, the "spf2" version takes precedence for the
desired scope-id. If the "spf2" record does not contain the
desired scope-id, then the "v=spf1" record is selected.
5. If an "spf2" record does not contain the desired scope-id and
there is no "v=spf1" record for the domain, then no record is
selected.
After the above steps, there should be one record remaining and
evaluation can proceed. If there are two or more records remaining,
then check_host() exits immediately with the error "PermError".
If the PRA version of the test is being performed and no records
remain, the requirement in [SPF] to find the Zone Cut and repeat the
above steps is OPTIONAL.
If there are no matching records remaining after the initial DNS
query or any subsequent optional DNS queries, then check_host()
exits immediately with the result "None".
5. Actions Based on the Decision
When the Sender ID test is used by an SMTP server as part of
receiving a message, the server should take the actions described by
this section.
The check_host() function returns one of the following results. See
[SPF] for the meaning of these results.
5.1 Neutral, None, SoftFail or PermError
An SMTP server receiving one of these results SHOULD NOT reject the
message for this reason alone, but MAY subject the message to
Lyon, Wong Experimental [Page 9]
Sender ID: Authenticating E-Mail May 2005
heightened scrutiny by other measures, and MAY reject the message as
a result of this heightened scrutiny.
Such additional security measures MAY take into account that a
message for which the result is "SoftFail" is less likely to be
authentic than a message for which the result is "Neutral".
5.2 Pass
An SMTP server receiving this result SHOULD treat the message as
authentic. It may accept or reject the message depending on other
policies.
5.3 Fail
When performing the Sender-ID test during an SMTP transaction, an MTA
receiving this result SHOULD reject the message with a "550 5.7.1
Sender ID (xxx) yyy - zzz" SMTP error, where "xxx" is replaced with
"PRA" or "MAIL FROM", "yyy" is replaced with the additional reason
returned by the check_host() function and "zzz" is replaced with the
explanation string returned by the check_host() function.
When performing the Sender-ID test after accepting an e-mail message
for delivery, an MTA receiving this result SHOULD not deliver the
message. Instead, it should create a DSN message, consistent with the
usual rules for DSN messages.
5.4 TempError
An SMTP server receiving this result MAY reject the message with a
"450 4.4.3 Sender ID check is temporarily unavailable" error code.
Alternatively, an SMTP server receiving this result MAY accept a
message and optionally subject it to heightened scrutiny by other
anti-spam measures.
Lyon, Wong Experimental [Page 10]
Sender ID: Authenticating E-Mail May 2005
6. Security Considerations
This entire document describes a new mechanism for mitigating spoofed
e-mail, which is today a pervasive security problem in the Internet.
Assuming that this mechanism is widely deployed, the following
sections describe counter-attacks that could be used to defeat this
mechanism.
6.1 DNS Attacks
The new mechanism is entirely dependent on DNS lookups, and is
therefore only as secure as DNS. An attacker bent on spoofing
messages could attempt to get his messages accepted by sending forged
answers to DNS queries.
An MTA could largely defeat such an attack by using a properly
paranoid DNS resolver. DNSSEC may ultimately provide a way to
completely neutralize this class of attacks.
6.2 TCP Attacks
This mechanism is designed to be used in conjunction with SMTP over
TCP. A sufficiently resourceful attacker might be able to send TCP
packets with forged from-addresses, and thus execute an entire SMTP
session that appears to come from somewhere other than its true
origin.
Such an attack requires guessing what TCP sequence numbers an SMTP
server will use. It also requires transmitting completely in the
blind - the attack will be unable hear any of the server's side of
the conversation.
Attacks of this sort can be ameliorated if IP gateways refuse to
forward packets when the source address is clearly bogus.
6.3 Forged Sender Attacks
This mechanism chooses an address to validate either from one of a
number of message headers or from the RFC2821 MAIL command, and then
uses that address for validation. A message with a true Resent-From
header or Return-Path, but a forged From header will be accepted.
Since many MUAs do not display all of the headers of received
messages, the message will appear to be forged when displayed.
Lyon, Wong Experimental [Page 11]
Sender ID: Authenticating E-Mail May 2005
In order to neutralize this attack, MUAs will need to start
displaying at least the address that was verified. In addition MTAs
could subject messages to heightened scrutiny when the validated
address differs from the From header.
6.4 Address Space Hijacking
This mechanism assumes the integrity of IP address space for
determining whether a given client is authorized to send messages
from a given PRA. In addition to the TCP attack given in section
6.2, a sufficiently resourceful attacker might be able to alter the
IP routing structure to permit two-way communication using a
specified IP address. It would then be possible to execute an SMTP
session that appears to come from an authorized address, without the
need to guess TCP sequence numbers or transmit in the blind.
Such an attack might occur if the attacker obtained access to a
router which participates in external BGP routing. Such a router
could advertise a more specific route to a rogue SMTP client,
temporarily overriding the legitimate owner of the address.
6.5 Malicious DNS attacks on third-parties
There is class of attacks in which an attacker A can entice a
participant P to send a malicious message to a victim V.
These attacks are undertaken by A citing the address of V in the SMTP
MAIL FROM request and then by causing P to generate (or invoke the
generation of) a Delivery Status Notification 'bounce' message
(RFC3464), which is sent to the victim V.
The attacker relies upon it being common practice to copy the
original message into the 'bounce' report, thereby causing the malice
to be sent onwards to V.
This mode of attack has the advantages (to the attacker) of
obfuscating the location of the host from which the attack was
mounted, and of possibly damaging the reputation of P by making it
appear that P originated or was an active participant in the sending
of the malicious message.
In current practice, A causes P to cause the 'bounce' by addressing
the original message to a non-existent recipient.
Sender-ID enables a new variant of this attack.
Lyon, Wong Experimental [Page 12]
Sender ID: Authenticating E-Mail May 2005
In this variant the attacker A sends a message whose PRA (section 4)
is selected by the attacker to be such that, when P undertakes the
Sender-ID test, a 'Fail' will result (section 5.3).
The message will be rejected (as the attacker intended) and a
malicious 'bounce' message may be generated and sent to the victim V.
7. Implementation Guidance
This section describes the actions that certain members of the
Internet e-mail ecosystem must take to be compliant with this
specification.
7.1 Simple E-mailers
A domain that injects original e-mail into the Internet, using its
own name in From headers, need do nothing to be compliant. However,
such domains SHOULD publish records in DNS as defined by [SPF] and
this specification.
In the majority of cases, the domain's published information will be
the same for both the PRA and MAIL FROM variants of this test. In
this case, domains SHOULD publish their information using an SPF
record with the prefix "v=spf1". Doing so will render their
published information usable by the older SPF protocol, too. (See
[SPF] for information on the SPF protocol.)
7.2 E-Mail Forwarders
In order to pass the PRA variant of the test, a program that forwards
received mail to other addresses MUST add an appropriate header that
contains an e-mail address that it is authorized to use. Such
programs SHOULD use the Resent-From header for this purpose.
In order to pass the MAIL FROM variant of the test, a program that
forwards received mail to other addresses MUST alter the MAIL FROM
address to an address under its control. Should that address
eventually receive a DSN relating to the original message, that DSN
SHOULD be forwarded to the original MAIL FROM address. However, if
this altered address receives any messages other than DSNs related to
the original message, these messages MUST NOT be forwarded to the
original MAIL FROM address; they SHOULD be refused during an SMTP
transaction.
Lyon, Wong Experimental [Page 13]
Sender ID: Authenticating E-Mail May 2005
Additionally, e-mail forwarders SHOULD publish Sender ID records for
their domains, and SHOULD use MTAs for which the Sender ID check
yields a "pass" result.
Some of today's forwarders already add an appropriate header
(although many of them use Sender rather than Resent-From.) Most of
them do not perform the address-rewriting specified above.
Note that an e-mail forwarder might receive a single message for two
or more recipients, each of whom requests forwarding to a new
address. In this case, the forwarder's MTA SHOULD transmit the
message to each new recipient individually, with each copy of the
message containing a different newly inserted Resent-From header
field.
7.3 Mailing List Servers
In order to pass the PRA variant of the test, a mailing list server
MUST add an appropriate header that contains an e-mail address that
it is authorized to use. Such programs SHOULD use the Resent-From
header for this purpose.
In order to pass the MAIL FROM variant of the test, a mailing list
server MUST alter the MAIL FROM address to an address under its
control.
Additionally, mailing list servers SHOULD publish Sender ID records
for their domains, and SHOULD use MTAs for which the Sender ID check
yields a "pass" result.
Most of today's mailing list software already adds an appropriate
header (although most of them use Sender rather than Resent-From),
and most of them already alter the MAIL FROM address.
7.4 Third-Party Mailers
In order to pass the PRA variant of this test, a program that sends
mail on behalf of another user MUST add an appropriate header that
contains an e-mail address that it is authorized to use. Such
programs SHOULD use the Sender header for this purpose.
In order to pass the MAIL FROM variant of this test, a program that
sends mail on behalf of another user MUST use a MAIL FROM address
that is under its control. Defining what the program does with any
mail received at that address is beyond the scope of this document.
Lyon, Wong Experimental [Page 14]
Sender ID: Authenticating E-Mail May 2005
Additionally, third-party mailers servers SHOULD publish Sender ID
records for their domains, and SHOULD use MTAs for which the Sender
ID check yields a "pass" result.
Many, but not all, of today's third-party mailers are already
compliant with the PRA variant of the test. The extent to which
mailers are already compliant with the MAIL FROM variant of this test
is unknown.
7.5 MUA Implementers
When displaying a received message, an MUA SHOULD display the
purported responsible address as defined by this document whenever
that address differs from the RFC 2822 From address. This display
SHOULD be in addition to the RFC 2822 From address.
When a received message contains multiple headers that might be used
for the purported responsible address determination, an MUA should
consider displaying all of them. That is, if a message contains
several Resent-From's, a Sender and a From, an MUA should consider
displaying all of them.
Sender ID also does not validate the display name that may be
transmitted along with an e-mail address. The display name is also
vulnerable to spoofing and other forms of attacks. In order to
reduce the occurrence and effectiveness of such attacks, MUA
implementers should consider methods to safeguard the display name.
This could include:
* Not presenting the display name to the user at all, or not
presenting the display name unless the corresponding e-mail
address is listed in the user's address book.
* Treating as suspicious any e-mail where the display name is itself
in the form of an e-mail address, especially when it differs from
the actual e-mail address in the header.
* Making it clear to users that the e-mail address has been checked
rather than the display name.
8. IANA Considerations
This document contains no actions for IANA.
Lyon, Wong Experimental [Page 15]
Sender ID: Authenticating E-Mail May 2005
9. Acknowledgements
This design is based on earlier work published in 2003 in [RMX] and
[DMP] drafts (by Hadmut Danisch and Gordon Fecyk respectively). The
idea of using a DNS record to check the legitimacy of an e-mail
address traces its ancestry to "Repudiating Mail From" draft by Paul
Vixie [Vixie] (based on suggestion by Jim Miller) and to "Domain-
Authorized SMTP Mail" draft by David Green [Green] who first
introduced this idea on namedroppers mailing list in 2002.
The current document borrows heavily from each of the above, and
incorporates ideas proposed by many members of the MARID working
group. The contributions of each of the above are gratefully
acknowledged.
10. References
10.1 Normative References
[PRA] J. Lyon, "Purported Responsible Address in E-Mail
Messages", draft-lyon-senderid-pra-01. Work in progress.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119.
[SPF] M. Wong and W. Schlitt, "Sender Policy Framework:
Authorizing Use of Domains in E-Mail", draft-
schlitt-spf-classic-00. Work in progress.
[Submitter] E. Allman and H. Katz, "SMTP Service Extension for
Indicating the Responsible Submitter of an E-mail
Message", draft-katz-submitter-00. Work in progress.
10.2 Informative References
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical
Specification,
http://www.microsoft.com/mscorp/twc/privacy/spam_callerid
.mspx.
[Green} David Green, "Mail-Transmitter RR",
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/
msg00656.html, June 2002.
[RMX] H. Danisch, "The RMX DNS RR and method for lightweight
SMTP sender authorization", draft-danisch-dns-rr-smtp-04.
Work in progress.
Lyon, Wong Experimental [Page 16]
Sender ID: Authenticating E-Mail May 2005
[Vixie] Paul Vixie, "Repudiating Mail From",
http://ops.ietf.org/lists/namedroppers/namedroppers.2002/
msg00658.html, June 2002.
11. Authors' Addresses
Jim Lyon
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
USA
jimlyon@microsoft.com
Meng Weng Wong
Singapore
mengwong@dumbo.pobox.com
Lyon, Wong Experimental [Page 17]
Sender ID: Authenticating E-Mail May 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lyon, Wong Experimental [Page 18]