General comment is that this draft text does not address the issue of
reusing v=spf1 records for SenderID without prior consent of the
publishers of the records. It should be a required part of the statement
or it'll not have support of SPF Community especially as you were
preparing to have this voted on in the future.
Also when you write complete text, because "Sender ID" is registered trademark
(not by Microsoft who is ignoring this issue) in some parts of the world
(UK and probably applies to entire EU), please have this mentioned as
small subnote on the buttom after the text with reference to it (i.e.
html bookmark link) from the first mention in the text.
On Sat, 11 Dec 2004, Chuck Mead wrote:
Chuck Mead wrote:
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.
I guess its ok, just a bit toothless for me....
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.
Ok.
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.
If you're mentioning DK and IIM, S/MIME and PGP you should mention
META Signatures especially since it builds on top of all of them and
basicly is a unification of mail signing approaches into one compatible
system. The core of that spec is now ready for implementation:
http://www.elan.net/~william/emailsecurity/meta_signatures_v017.htm
I'm now putting together couple servers for exclusive use for testing and
development for META and sourceforge project is also registered. Will
start library development for it within next 7 days (you will see
announcement) and I already have at least 5 parties of various sized but
including those with 100k users who are interested in working on it and
testing it.
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
I have serious problem with "Sender ID reuses SPF records to perform the
PRA test". I would like to see that as
Sender ID reuses SPF record syntax to allow domain owners to provide
information for PRA test
But I note that in latest Sender ID specs it is exactly as Chuck wrote,
i.e. it directly reuses SPF records and that is a big problem that
SPF council should be addressing in its statement.
not Sender ID, and Sender ID is not SPF.
To make it more clear, change above line to:
"not Sender ID and is not part of it, and SenderID is not the same as SPF"
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net