In <87837583(_dot_)1102808910(_at_)[192(_dot_)168(_dot_)0(_dot_)2]> Greg Connor
<gconnor(_at_)nekodojo(_dot_)org> writes:
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.
I agree.
Keep in mind that this was the last subject to be brought up at the
meeting and it was after an hour and a half of discussion. What Chuck
posted was basically a dump of the last version we worked on and we
all agreed it needs more work.
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.
Yes, I think this is very important.
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.
Yes.
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.
Several of us would object to even saying that it is 'still' going
strong, because that implies that SPF may be running out of steam.
SPF is not only the leading email anti-forgery system out there, it
has more deployment than all others combined and is growing more
rapidly.
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).
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.
Greg suggested a while ago on the SPF position statement on SenderID
that we break up that statement into several parts. I think this was
what the council was trying to do (or, at least that was my intent).
My intent was to try and craft another statement about the problems
with the PRA, if we actually decide we need to say something about
that. So, I don't view this as being off the table, but could be
depending on other factors.
I also think that a vote about the SPF position statement on SenderID
is still a possibilty, if for no other reason than I said I was going
to bring it to a vote on the council.
-wayne