"From" and other Message Header Fields as SPF Policy Scopes

Sender Policy Framework (SPF) 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 was designed to overcome this limitation of SPF by defining an artificial identity named Purported Responsible Address (PRA) based on one of the "From", "Sender", "Resent-From", and "Resent-Sender" message header fields. 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 , 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 , such as the "From" or "Sender" message header identities.

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 .

This specification uses the Augmented Backus-Naur Form (ABNF) 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).

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.

Per Section 3.6.2 of 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 ) 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 . Such a messages has no "From" header identity. A message with more than one "From" header field is invalid per , 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.

Per Section 3.6.2 of 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 ) 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 identities (as multiple mailbox specifications in a single or in multiple "From" header field(s)) is invalid per , 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 , 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.

This document defines a new modifier named "scope" for use in SPF "v=spf1" policies as provided by Section 6 of . 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 of this document hdr-sender of this document 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.

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 , 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 ; 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.

Lots of headaches to be considered.