datatracker.ietf.org
Sign in
Version 5.4.0, 2014-04-22
Report a bug

SPF Update
charter-ietf-spfbis-01

Snapshots: 01
Charter for "SPF Update" (spfbis) WG
WG State: Active
Charter State:
Responsible AD: none

Send notices to: none
Last updated: 2012-02-07

Other versions: plain text

Charter charter-ietf-spfbis-01

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.