Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
RFC 4408
Document | Type |
RFC - Experimental
(April 2006; Errata)
Obsoleted by RFC 7208
Updated by RFC 6652
Was draft-schlitt-spf-classic (individual in app area)
|
|
---|---|---|---|
Authors | Wayne Schlitt , Meng Wong | ||
Last updated | 2020-01-21 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized with errata bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 4408 (Experimental) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Ted Hardie | ||
Send notices to | (None) |
Network Working Group M. Wong Request for Comments: 4408 W. Schlitt Category: Experimental April 2006 Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1 Status of This Memo This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). IESG Note The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such, these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group. The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them. Note that the Sender ID experiment may use DNS records that may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt. Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. aParticipants publishing SPF experiment DNS records should consider the advice given in section 3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict. Wong & Schlitt Experimental [Page 1] RFC 4408 Sender Policy Framework (SPF) April 2006 Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem. The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future. Abstract E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization. Table of Contents 1. Introduction ....................................................4 1.1. Protocol Status ............................................4 1.2. Terminology ................................................5 2. Operation .......................................................5 2.1. The HELO Identity ..........................................5 2.2. The MAIL FROM Identity .....................................5 2.3. Publishing Authorization ...................................6 2.4. Checking Authorization .....................................6 2.5. Interpreting the Result ....................................7 2.5.1. None ................................................8 2.5.2. Neutral .............................................8 2.5.3. Pass ................................................8 2.5.4. Fail ................................................8 2.5.5. SoftFail ............................................9 2.5.6. TempError ...........................................9 2.5.7. PermError ...........................................9 3. SPF Records .....................................................9 3.1. Publishing ................................................10 3.1.1. DNS Resource Record Types ..........................10 3.1.2. Multiple DNS Records ...............................11Show full document text