Re: [spfbis] Updated charter - final review

[Commerco WebMaster <[e-mail]>]

Looks good, thank you.

Alan M.

On 1/31/2012 11:29 PM, Pete Resnick wrote:
> All,
>
> I have made some updates to the charter based on feedback during IESG
> review. If I can sneak it onto the Thursday telechat this week, I might,
> but the IESG might be none too pleased for me to put it on so late, so
> it may wait two more weeks. We'll see.
>
> Please review the below and see if there is anything that makes your
> head explode.
>
> pr
>
> ---
>
> Working Group Name:
> SPF Update (SPFBIS)
>
> IETF Area:
> Applications Area
>
> Chair(s):
> TBD
>
> Applications Area Director(s):
> Pete Resnick<[e-mail]>
> Peter Saint-Andre<[e-mail]>
>
> Applications Area Advisor:
> Pete Resnick<[e-mail]>
>
> Mailing Lists:
> General Discussion:[e-mail]
> 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:
> Aug 2012: A document describing the SPF/Sender-ID experiment
> and its conclusions to the IESG for publication.
>
> Dec 2012: A standards track document defining SPF,
> based on RFC4408 and as amended above,
> to the IESG for publication.
>