IETF-86 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

SPF Update (spfbis) (WG)

Minutes   |   Audio Archives  |   Jabber Logs  |   Mailing List Archives

Additional information is available at tools.ietf.org/wg/spfbis

Chair(s):

Applications Area Area Director(s):

Applications Area Advisor



Meeting Slides:

No Slides Present

Internet-Drafts:

Request for Comments:

Charter (as of 2012-02-07):


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.

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