Re: [spfbis] Updated charter - final review

[Hector Santos <[e-mail]>]

Pete,

Now that I have a better change (more time) to review the charter, 
there is one item that I think may be important related to SENDER-ID 
from the standpoint of RFC 4405 SUBMITTER SMTP Extension.

To begin the WG spec discussions, I was going to propose the following 
to modify section 4.1:

4.1.  Arguments

    The check_host() function takes these arguments:

    <ip>     - the IP address of the SMTP client that is emitting the
               mail, either IPv4 or IPv6.

    <domain> - the domain that provides the sought-after authorization
               information; initially, the domain portion of the "MAIL
               FROM" or "HELO" identity.

    [submitter] - RFC 4409, SUBMITTER keyword passed to the "MAIL FROM"

but then I though it may not fit the charter with the way SENDER-ID is 
discussed.

Background:

In our implementation, if the SUBMITTER keyword is provided to the 
MAIL FROM, it is passed to our SPF implementation check_host() function:

   result = check_host(ip, domain [, submitter])

The tie-in, even for the SPF implementator who may not directly 
support SENDER-ID, it could be supporting RFC 4405 because it is a 
SMTP level protocol and it allows SMTP systems the NON-PAYLOAD 
affordability to support SENDER-ID indirectly.

In my opinion, I think it has technical and operational merit to 
consider how implementations has supported SENDER-ID via the SUBMITTER 
keyword.

However, the charter does ring with the idea that the industry are no 
longer interested in SENDER-ID. I don't think we can make that 
decision for anyone. Perhaps a statement should be added to the 
charter or revised it to clarify the lack of WG consideration for 
SENDER-ID does not imply it is no longer supported and that RFC4405 
MAY be supported via SPF-BIS.

If anything, the check_host() arguments SHOULD be changed to be 
flexible with optional parameters and not locked in and using RFC4405 
is a valid technical rational as an example optional parameter without 
having to introduce SENDER-ID discussions.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


Hector Santos wrote:
> +1, looks good to me.
> 
> -- 
> HLS
> 
> 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.
>>
>