SPF Update (spfbis)

Last modified: 2014-04-25

Chairs

Applications Area Directors

Applications Area Advisor

Mailing Lists:

General Discussion: spfbis@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/spfbis
Archive: http://www.ietf.org/mail-archive/web/spfbis/

Description of Working Group:

The Sender Policy Framework (SPF, RFC4408) specifies the publication of a DNS record which states that a listed IP address is authorized to send mail on behalf of the listing domain name's owner. SMTP servers extract the domain name in the SMTP "MAIL FROM" or "HELO" command for confirming this authorization. The protocol has had Experimental status for some years and has become widely deployed. This working group will summarize the result of the experiment and revise the specification, based on deployment experience and listed errata, and will seek Standards Track status for the protocol.

The MARID working group considered two specifications for publication of email-sending authorization: Sender-ID, which eventually became RFC4405, RFC4406 and RFC4407, and SPF, which eventually became RFC4408, all in the end published under Experimental status. By using IP addresses, both protocols specify authorization in terms of path, though unlike SPF, Sender-ID uses domain names found in the header of the message rather than the envelope.

The two protocols rely on the same policy publication mechanism, namely a specific TXT resource record in the DNS. This creates a basic ambiguity about the interpretation of any specific instance of the TXT record. Because of this, there were concerns about conflicts between the two in concurrent operation. The IESG note prepended to RFC 4405 through RFC 4408 defined an experiment with SPF and Sender-ID, and invited an expression of community consensus in the period following the publication of those specifications.

Both technologies initially enjoyed widespread deployment. Since that time, broad SPF use has continued, whereas use of Sender-ID has slackened. Furthermore, SPF's linkage to the envelope (as opposed to Sender-ID's linkage to identifiers in the message content) has proven sufficient among operators.

Formation of the SPF Update Working Group is predicated on three assumptions:

  1. The SPF/Sender-ID experiment has concluded.

  2. SPF has been a qualified success, warranting further development.

  3. Sender-ID has had less success, and no further development is justified.

The working group will produce a document describing the course of the SPF/Sender-ID experiment, thus bringing that experiment to a formal conclusion. The group will complete additional work on SPF (described below), but will not complete additional work on the Sender-ID specification.

Changes to the SPF specification will be limited to the correction of errors, removal of unused features, addition of any enhancements that have already gained widespread support, and addition of clarifying language.

Specifically out-of-scope for this working group:

  • Revisiting past technical arguments where consensus was reached in the MARID working group, except where review is reasonably warranted based on operational experience.
  • Discussion of the merits of SPF.
  • Discussion of the merits of Sender-ID in preference to SPF.
  • Extensions to the SPF protocols.
  • Removal of existing features that are in current use.

Discussion of extensions to the SPF protocols or removal of existing features shall only be discussed after completion of current charter items in anticipation of rechartering the working group.

An initial draft of an updated SPF specification document is draft-kitterman-4408bis. The working group may choose to use this document as a basis for their specification.

Goals and Milestones

Done A document describing the SPF/Sender-ID experiment and its conclusions to the IESG for publication.
Done
A standards track document defining SPF, based on RFC4408 and as amended above, to the IESG for publication.

Request for Comments

 

Internet SocietyAMSHome - Tools Team - Datatracker - IASA - IAB - RFC Editor - IANA - IRTF - IETF Trust - ISOC - IETF Journal - Store - Contact Us
Secretariat services provided by Association Management Solutions, LLC (AMS).
Please send problem reports to: ietf-action@ietf.org.