Internet DRAFT - draft-mehnle-spf-scope
draft-mehnle-spf-scope
Network Working Group J. Mehnle
Internet-Draft Authentication Metrics
Intended status: Standards Track December 1, 2011
Expires: June 3, 2012
"From" and other Message Header Fields as SPF Policy Scopes
draft-mehnle-spf-scope-00
Abstract
This document defines a new modifier for the SPF e-mail
authentication protocol allowing the SPF record for a domain to be
declared as being applicable to message identities other than the
MAIL FROM identity, such as the "From" or "Sender" message header
identities.
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 http://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 June 3, 2012.
Copyright Notice
Copyright (c) 2011 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
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include 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.
Mehnle Expires June 3, 2012 [Page 1]
Internet-Draft Extended Scopes for SPF December 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . . 3
2. Supported Message Identities . . . . . . . . . . . . . . . . . 4
2.1. The "From" Header Identity . . . . . . . . . . . . . . . . 4
2.2. The "Sender" Header Identity . . . . . . . . . . . . . . . 4
3. The "scope" modifier . . . . . . . . . . . . . . . . . . . . . 5
3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Normative References . . . . . . . . . . . . . . . . . . . 7
5.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7
Mehnle Expires June 3, 2012 [Page 2]
Internet-Draft Extended Scopes for SPF December 2011
1. Introduction
Sender Policy Framework (SPF) [RFC4408] was designed to prevent the
unauthorized use of domain names in the reverse-path of e-mail
messages (also known as the envelope sender or MAIL FROM identity).
However, the reverse-path is used purely for message transport
purposes and in practice is never exposed to the end user, so SPF
cannot protect against typical forms of address spoofing targeting
user visible identities such as the "From" message header field.
Sender ID [RFC4406] was designed to overcome this limitation of SPF
by defining an artificial identity named Purported Responsible
Address (PRA) [RFC4407] based on one of the "From", "Sender",
"Resent-From", and "Resent-Sender" message header fields [RFC5322].
The algorithm underlying the PRA definition was intended to select
the identity representing the entity responsible for the message's
most recent injection into the mail system. The "Resent-From" and
"Resent-Sender" fields, however, too, are rarely exposed to the end
user, so by taking these into consideration PRA-based Sender ID
policies open themselves up to attacks where the "From" header
address is spoofed and a "Resent-From" or "Resent-Sender" field is
added -- typically invisible to the end user -- with an unrelated
(usually unprotected) address.
This document defines a new "scope" modifier, as provided by Section
6 of [RFC4408], for use in SPF "v=spf1" policies. Policies that
include a "scope" modifier may be used to authenticate message
identities other than the HELO or MAIL FROM identities defined by
[RFC4408], such as the "From" or "Sender" message header identities.
1.1. Conventions Used in This Document
1.1.1. Requirements Notation
This document occasionally uses terms that appear in capital letters.
When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD
NOT", and "MAY" appear capitalized, they are being used to indicate
particular requirements of this specification. A discussion of the
meanings of these terms appears in [RFC2119].
1.1.2. Syntactic Notation
This specification uses the Augmented Backus-Naur Form (ABNF)
[RFC5234] notation for formal syntax definitions. Characters will be
specified either by a decimal value (e.g., the value %d65 for
uppercase A and %d97 for lowercase A) or by a case-insensitive
literal value enclosed in quotation marks (e.g., "A" for either
uppercase or lowercase A).
Mehnle Expires June 3, 2012 [Page 3]
Internet-Draft Extended Scopes for SPF December 2011
2. Supported Message Identities
The "scope" modifier allows a domain owner to specify a set of
message identities to which a domain's SPF policy may be applied in
addition to the default HELO and MAIL FROM identities to which all
"v=spf1" policies may be applied. This section defines the
identities that may be specified as part of a "scope" modifier.
Other documents may define additional identities.
2.1. The "From" Header Identity
Per Section 3.6.2 of [RFC5322] a typical e-mail message includes a
single "From" header field containing a single mailbox specification
indicating the mailbox of the person or system responsible for
authoring the message. The addr-spec part (Section 3.4 of [RFC5322])
of that mailbox constitutes the "From" header identity of such a
message.
A message's "From" header field may contain more than one mailbox
specification if the message was authored by multiple persons. Such
a message has multiple "From" header identities.
A message with zero "From" header fields is invalid per [RFC5322].
Such a messages has no "From" header identity.
A message with more than one "From" header field is invalid per
[RFC5322], however in order to prevent the display or other use of
unintentionally unauthenticated identities from such a message it is
RECOMMENDED that in this case implementations of this specification
treat all the mailbox specifications in all the "From" header fields
as multiple "From" header identities for the purposes of this
document.
2.2. The "Sender" Header Identity
Per Section 3.6.2 of [RFC5322] an e-mail message may include a single
"Sender" header field containing a single mailbox specification
indicating the mailbox of the person or system responsible for
originally sending the message. The addr-spec part (Section 3.4 of
[RFC5322]) of that mailbox constitutes the "Sender" header identity
of such a message.
A message with zero "Sender" header fields is assumed to have been
sent by its author, as specified by a single "From" header field with
a single mailbox specification. Such a message's "Sender" header
identity is its "From" header identity.
A message with zero "Sender" header fields and multiple "From" header
Mehnle Expires June 3, 2012 [Page 4]
Internet-Draft Extended Scopes for SPF December 2011
identities (as multiple mailbox specifications in a single or in
multiple "From" header field(s)) is invalid per [RFC5322], however in
order to prevent the display or other use of unintentionally
unauthenticated identities from such a message it is RECOMMENDED that
in this case implementations treat multiple "From" header identities
as multiple "Sender" header identities for the purposes of this
document.
A message with a single "Sender" header field containing multiple
mailbox specifications or with more than one "Sender" header field is
invalid per [RFC5322], however it is RECOMMENDED that in this case
implementations treat all the mailbox specifications in all the
"Sender" header fields as multiple "Sender" header identities for the
purposes of this document.
3. The "scope" modifier
3.1. Syntax
This document defines a new modifier named "scope" for use in SPF
"v=spf1" policies as provided by Section 6 of [RFC4408]. The grammar
is as follows:
mod-scope = "scope" "=" scope-ids
scope-ids = scope-id *( "," scope-id )
scope-id = "hdr-from" / "hdr-sender" / name
An SPF policy may contain at most one "scope" modifier; an
implementation encountering more than one "scope" modifier in a
policy MUST generate a "PermError" result. The single "scope"
modifier MAY occur anywhere in the record after the initial "v=spf1",
however it is RECOMMENDED that it be inserted immediately after the
initial "v=spf1" to make it clear that the semantics associated with
it apply to the entire policy; of course this is always the case,
even if the "scope" modifier occurs in a different position.
<scope-id> values are defined as follows:
+------------+------------------------------+
| Identity | Defined in |
+------------+------------------------------+
| hdr-from | Section 2.1 of this document |
| hdr-sender | Section 2.2 of this document |
+------------+------------------------------+
Mehnle Expires June 3, 2012 [Page 5]
Internet-Draft Extended Scopes for SPF December 2011
For example, the SPF record
v=spf1 scope=hdr-from ip4:192.168.0.101 -all
defines a sender policy that may be used to authenticate "From"
header identities in messages.
3.2. Semantics
An SPF policy that includes a "scope" modifier may be used to
authenticate the message identities specified as a separated list of
<scope-id>s in the modifier value. The set of identities listed is
said to be the (extended) scope of the policy. A supported identity
is said to be "in scope" of a policy if it is listed in the policy's
scope modifier.
Authentication of a supported, in-scope message identity against an
SPF policy is done by applying the check_host() function defined in
Section 4 of [RFC4408], passing the identity as the <sender> argument
and its domain portion as the <domain> argument.
When authenticating a certain type of identity in a given message and
the message does not contain any instances of that identity, there is
nothing to authenticate.
When authenticating a certain type of identity in a given message and
the message contains multiple distinct instances of that identity,
the result of each check applies only to a single distinct instance
of the identity. It is RECOMMENDED that an implementation check all
the instances of a type of identity that it chooses to authenticate.
Then, for example, individual identity instances may be marked
according to their results when displaying the message to the end
user, or an aggregate result may be derived from the individual
results. The precise behavior is not defined by this document except
that, for a given message, all instances of a given identity type
MUST be treated according to the same rules. Implementations MUST
NOT simply select one of them as "the" identity of that type.
NOTE: The support of modifiers defined by specifications other than
the base SPF specification is generally optional and domain owners
should be aware that their "v=spf1" policies will be used by
receivers to authenticate the default HELO and MAIL FROM identities
defined by [RFC4408]; there is no way to prevent that. "v=spf1"
policies with a "scope" modifier published with the primary intent of
allowing the authentication of non-HELO, non-MAIL-FROM identities
should be constructed in such a way that legitimate messages sent
with relevant HELO or MAIL FROM identities will not unexpectedly fail
authentication of these identities.
Mehnle Expires June 3, 2012 [Page 6]
Internet-Draft Extended Scopes for SPF December 2011
4. Security Considerations
Lots of headaches to be considered.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-Mail, Version 1",
RFC 4408, April 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008.
5.2. Informative References
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
RFC 4406, April 2006.
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail
Messages", RFC 4407, April 2006.
Author's Address
Julian Mehnle
Authentication Metrics, Inc.
Email: jmehnle@authmetrics.com
Mehnle Expires June 3, 2012 [Page 7]
