On Sat, 11 Dec 2004, Greg Connor wrote:
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.
That was my view as well, but I suspect Greg has very different view on
how to overcome fuzzy - for me it means getting more to the point and for
example while original statement correctly said that senderid
"is not technically appropriate in a range of situations" and
"PRA may offer benefits to certain segments of the email industry"
it should have been made clear that the segments that want to benefit
from senderid are exactly the ones where PRA is technically flowed.
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.
No problem. Next time I'll bash SID, I'll not mention SPF :)
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.
Agreed.
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.
Agreed.
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).
I disagree here. I believe technical problems with SID should be mentioned,
It is possible however that for general statement getting into specifics
of such problems is too much and while I thought original text was
"fuzzy" as Greg put it, I did not seriouly object to it.
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.
I disagree, I think its a big issue and it does deserve its own statement
which should should be more detailed, I do believe this general statement
MUST mention issues with reuse of v=spf1 record. I also disagree with
labeling this a "technical issue" - its not technical issue at all, its
issue of reusing records designed for one type of email policy for
different type of email policy system and result is that domain owner
may see email rejections that he would never have anticipated when
originally publishing spf records.
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.
I have no problem with above paragraph but only as far as it having replaced
the 2nd of the paragrpaphs in original statement draft. I do not believe
removing the first one is good idea and I also think that we should start
with SID (since this is statement regardinng SID) and not start with SPF
Classic and then go to SID so in such a way I believe original was better.
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.
I believe original text was better the above two paragraphs.
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.
In above I actually agree with changing order and think that ending with
different technologies is better. But I would be against "enouragement
of development of SenderID and PRA" since this is statement from SPF,
it should be quite clear to the council that SPF Community is against
development of SenderID, so above phrase is paragraph would simply be
a false representation of SPF position.
I'm now going to work on the text Greg wrote above (much of it quite
good) and on text originally posted by Chuck and on another statement
by Greg (regarding reuse of spf1) and try to provide my version for
SPF-statement on SID. Hopefully after that somebody else can give it
a try.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net