Re: Re: spf-statement-on-SenderID
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
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.
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
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
Greg Connor <gconnor(_at_)nekodojo(_dot_)org>