I guess after thinking more about it and working with a text, I decided
that Greg was right and starting with SPF may not be a bad idea (I also
looked at statments made by other companies and they often start with
quickly telling about the company and then move it the point.
So here is my take on the statement text (it includes text that Chuck
wrote as has been modifed by Greg as well as couple paragraphs from
what Greg prepared for statement draft on SID reuse of v=spf1 records):
----------------------------------------------------------------------
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
blow-back 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. Over 20% of Internet
email volume can be usefully tested with SPF Classic.
As there has been some confusion on the relationship between SPF and
Sender ID, we would like to clarify the relationship: While Sender ID
reuses SPF language and syntax to perform the PRA test, SPF Classic is
not the same as Sender ID as is not part of it. The two technologies
are complementary, but they operate on different parts of the message
and serve different purposes.
The PRA algorithm used by Sender ID uses headers more visible to the user,
and is more focused on phishing and fraud. However PRA algorithm has not
been widely tested, comes encumbered by a patent license, and its use
may not be technically appropriate in large range of situations that
are common today. But as SPF community welcomes other efforts to limit
electronic mail forgery and spam, the SPF community appreciates that
Sender ID may offer benefits to certain segments of the email industry.
SPF Community is concerned however about Sender ID reuse of SPF Classic
"v=spf1" records for PRA tests. The currently deployed version of SPF
records was designed to protect only the return-path address and we know
that there are a number of cases where using the "v=spf1" record
information in other contexts will give incorrect results, and this
can lead to missed expectations and potentially to delivery failures.
Further, we believe that the original intent of the domain owner who
published the record should be respected, and that implicitly using
data for other purposes is not appropriate. We feel that requiring
the publisher of the record to "opt out" of such use is not sufficient;
the domain owner should explicitly "opt in" before the data is used in
a new context.
And while current v=spf1 syntax does not currently extend to protecting
other parts of the message transaction, such as From: or other visible
headers, we expect that a future version of SPF (Unified SPF) will be
flexible enough to handle multiple context.
SPF Community encourages continued development of SPF and exploration of
other possible solutions in the accountable messaging space, including
further development and testing of path-based proposals such as Sender ID
and CSV, and cryptographic signature proposals such as Domain Keys,
Identified Internet Mail and Meta Signatures and we welcome continued use
and further deployment of S/MIME and PGP email security standards.
----------------------------------------------------------------------
---
William Leibzon, Elan Networks:
mailto: william(_at_)elan(_dot_)net
Anti-Spam and Email Security Research Worksite:
http://www.elan.net/~william/emailsecurity/