Re: Re: spf-statement-on-SenderID

Hi William,

Thanks for taking the time to revise.  I think I agree with the statement 
you prepared, but I think I had a different understanding of what the 
council wanted to state and why.
Perhaps one or two council members can chime in to this thread.  Where will 
the statement be published?  If it doesn't address all the community's 
concerns, when will other important concerns be addressed and how?
It seems pretty clear from the meeting transcript that the council didn't 
want to address the reuse issue here.  Which might be OK, depending on the 
purpose of the statement and where it is going to go.  For example, if we 
are putting it in a letter to send somewhere (like the FTC) then it should 
include everything that is important, but if it's going to go on a website 
then it can be short and sweet and the other "position" statements can 
appear other places on the site.
If we want something even shorter, my rewrite version (or Chuck's version 
for that matter) can be shortened a little by removing the references to 
"PRA's various problems" as well.  There are many SPF supporters who feel 
that PRA is bad, but not all of them do -- plus I think many SPF advocates 
would say that it's not really our place to discourage use of other 
technologies.
William, you wrote "it should be quite clear to the council that SPF 
Community is against development of SenderID" -- in that I suspect you are 
right, but if we specifically say "PRA has these flaws" we are moving 
further afield from discussing SPF -- that could be the difference between 
a "majority" statement and a "universal" statement.  In other words, 
there's a difference between "Most of us feel X" and "Most of us feel X 
should be our public position"
I'm not going to post another version, but let's discuss (and hopefully 
hear from Meng, Wayne, Julian, Chuck, Mark) on what the main purpose of the 
statement is, and whether that purpose is better served by a minimalist 
approach or an exhaustive statement.
Thanks
gregc

My rewrite version appears again here (no changes from last night)
> 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.
>
> 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>