Re: spf-statement-on-SenderID

Here are some comments on the council's draft position on differentiating 
SPF and SenderID.
The statement as posted by Chuck and in the meeting transcript is, a little 
fuzzy around the edges.  I think it says what the council wanted to say but 
comes out with the purpose a bit obscured.
After reading the meeting transcript, my understanding is that the council 
sees a need for the following:
1. Differentiate SPF and SenderID, so that people don't think SenderID is 
the inheritor of SPF.  Make it easier for those who choose to bash SenderID 
to do so without smearing SPF's good name.
2. Clarify that even though the SPF language is used to build PRA records 
as well, this is an "off-label" use and not really related to the core of 
SPF.
3. Make sure that people reading the statement understand that SPF Classic 
is still "going strong" and is not going to be replaced by SenderID.
4. NOT saying that PRA is bad, or that we discourage its use, just that we 
recognize a couple of barriers, and these barriers to SenderID don't apply 
to SPF Classic.  (Subtext: If PRA fails, SPF will not be affected by that).
5. NOT mention technical issues such as reuse of v=spf1 records in this 
statement, because this statement needs to go to a non-technical audience. 
Reuse of records deserves attention, but should be its own statement 
separate from this one.

So here is an attempt to rephrase the council's first draft.  I think the 
rewrite should agree with the original statement in substance... the idea 
here is to just move stuff around a bit so that readers can pick up the 
main point quickly and read between the lines where we want them to.

--Chuck Mead <csm(_at_)MoonGroup(_dot_)com> wrote in spf-council:

> The SPF community recognizes that the PRA algorithm used by Sender ID
> has not been widely tested, comes encumbered by a patent license, and
> may not be technically appropriate in a range of situations that are
> common today.  However, the SPF community welcomes all efforts to
> limit electronic mail forgery and spam and the SPF community
> appreciates that the PRA may offer benefits to certain segments of the
> email industry.
>
> The SPF community simply wishes to inform any interested parties that
> SPF Classic, operating on the return-path, is a powerful weapon in
> this fight, that has been deployed in many antispam and MTA products
> already, and enjoys the support of an estimated 1 million domains.

Suggest rewriting these two as the following three:

SPF Classic is a powerful weapon in the fight to limit electronic mail 
forgery and spam.  It operates on the return-path (which occurs early in 
the mail transaction, before any headers) which makes possible to reduce 
blowback of misdirected bounces and reduces total bandwidth usage.  SPF 
Classic has been deployed in many antispam and MTA products already, and 
enjoys the support of an estimated 1 million domains.
The SPF community welcomes all efforts to limit electronic mail forgery and 
spam.  For example, the the PRA algorithm used by Sender ID uses headers 
more visible to the user, and is more focused on phishing and fraud.
We recognize that the PRA algorithm has issues to overcome.  It has not 
been widely tested, comes encumbered by a patent license, and may not be 
technically appropriate in many situations.  Once these issues are 
addressed, SenderID may soon offer benefits to certain segments of the 
email industry that need such protection.

> According to recent research, over 20% of Internet email volume can be
> usefully tested with SPF Classic.  We encourage continued development
> of SPF Classic in the email industry, as we encourage continued
> development and exploration of all other possibilities in the
> accountable messaging space, including path-based solutions such as
> Sender ID and CSV, and cryptographic solutions such as Domain Keys and
> Identified Internet Mail, not forgetting S/MIME and PGP.
>
> As there has been a distinct lack of clarity for some months on this
> issue, the SPF Community simply wishes to make it known that while
> Sender ID reuses SPF records to perform the PRA test, SPF Classic is
> not Sender ID, and Sender ID is not SPF.

Suggest rewriting these two as:

As there has been some confusion on the relationship between SPF and 
SenderID, we would like to clarify the relationship:  While Sender ID 
reuses SPF language and syntax to perform the PRA test, SPF Classic is not 
Sender ID, and Sender ID is not SPF.  The two technologies are 
complementary, but they operate on different parts of the message and serve 
different purposes.
SPF Classic has a bit of a headstart: according to recent research, over 
20% of Internet email volume can be usefully tested with SPF Classic.  We 
encourage continued development and deployment of SPF Classic.  We also 
encourage continued development and exploration of SenderID and PRA, as 
well as all other possibilities in the accountable messaging space, 
including CSV, Domain Keys and Identified Internet Mail, and even S/MIME 
and PGP.




--
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>