On Sun, 05 Dec 2004 17:48:41 GMT, wayne wrote
For the next SPF council meeting, I request that the SPF communities'
position on SenderID be put on the agenda.
One of my candidate pledges said:
I strongly support the "SPF Community Position on SenderID" as written
on http://www.openspf.org/OpenSPF_community_position_v102.html and
have signed it. Since this document was (obviously) written before
the elections, one of my first tasks would be to bring this to an
I have to admit, that I have done a lot of fence sitting on this one; and
I'm still not entirely off it. :)
I signed the pledge of the "Positions of the SPF Community in regards to
Sender ID". Signing a document in support of saying SenderID does SPF no
good, however, I feel is quite different from making on official SPF
statement to that effect. The former, as I see it, is just part of the
every-day job of talking about SPF; the latter is, yes, what exactly? We,
the SPF conmunity, discuss many things on a daily basis; BATV, CSV, SES,
and other initiatives out there, all these come up in discussions here,
from time to time. But would we not look silly, if tommorrow we published,
say, an "Official SPF position on BATV"? Naturally, SPF and SenderID are
more closely interwoven; I understand that. But my point is, while we may
all, at large, agree on SenderID being a bad thing, I think, on the whole,
we are better off, and more correct, in making "official" statements not
on why other products are bad, but as to why we feel SPF is a good thing.
I would, myself, not mind if we draft a white paper of sorts. In fact, I
talked about it on IRC, a few weeks ago. But I was more thinking along the
lines of formulating a solid technical response to the recent "sendmail"
whitepaper, for instance. After the likeness of that paper, I envision
that we, the council, could summarize our recommendations to the world for
doing certain things, or not doing them. Devoid of politics, that is. In
such a paper, I can readily see a section which talks about "The use of
SPF records and common pitfalls." Something like that. Without ever the
need to mention MicroSoft, yet still be very clear, in an informative
manner, how we feel SPF records should be handled/interpreted, and what
sort of (mis)use will lead to problems. Personally, that is the approach
which has my preference.
- Mark
System Administrator Asarian-host.net
--
"If you were supposed to understand it,
we wouldn't call it code." -- FedEx