I accept my nomination for the 2006 SPF Council.
Here are the things I consider important for the coming year:
o Top-of-the-list: Public relations.
(Not to plagiarize Julian here.)
(This is more urgent than the slow-moving state of the
standard, in the sense that no matter how the
appeal-versus-no-appeal decision goes, the standard will
eventually end up to be almost exactly matching its current
state, and there's little anyone can really do to speed
this process. Thus, day-to-day work will generally focus
elsewhere.)
It looks to me as if there are still widespread
misunderstandings on the basics goals of SPF, even among
folks (outside the general spf community) who seem to
understand the specifics.
This leads to logical-sounding fallacies that will quite
naturally make folks not want to implement SPF on either
the publishing or receiving side.
To address this I will:
o Work to improve website content, especially content
that addresses these fallacies.
o Ask spf programmers to add code or hooks to allow
as an end result that individual recipients can
easily enable or disable spf checking. (So
ISPs/ESPs will be more likely to allow more
end-user control.)
o Push for regular press releases to keep spf progress
in the press.
o Spec standardization: I'm currently undecided on the
issue of whether to push for an appeal; however, I am
currently leaning towards the appeal process.
My reasoning is that submitting a standard to a
standards implies a responsibility towards not only
working within the written and unwritten rules of the
organization, but also a responsibility to at least
some minor assistance in it's long-term stability.
In other words, I am currently concerned that avoiding
the next level of appeal almost pushes problems under the
rug.
As I have seen other organizations seemingly abandon ietf
processes or participation in an irresponsible manner, I
want to make sure that we do not do the same.
However, I'm still undecided on whether I think an additional
appeal would hurt or help spf long-term, as well as whether
avoiding an appeal would be acceptable or irresponsible for
the above reasons.
In general however, the importance of following through
with spec standardization, or helping Wayne in whatever way
I can, of course goes without saying.
o Continue to collect ideas for the next version of spf and lay
the groundwork for the next round of standardization to not
need to be as confrontational.
(In particular, re-examine the authentication-header
standards development, as something along those lines should
eventually replace Received-SPF and still be compatible with
other anti-forgery methods.)
o Talk with ISPs and ESPs to find the *real* reasons they're
not deploying SPF, and find a way to address their concerns.
(Note: As a contractor/consultant, this presents me the
potential of billable consulting time. Please be aware
of this if you believe this represents a conflict-of-interest
for me. I don't believe it does, but I want to disclose
any such possible issues.)
o Low priority:
Try again to approach Microsoft to see if they would be
interested in licensing their mail-forgery related patents
in an Open Source compatible manner. This has been tried
this in the past and failed, but we should try once more just
in case there's a possibility of healing-unnecessary-rifts
and allowing for a wider range of future SPF standards. This
is a lower priority item however, given past unsuccessful
attempts, and given the fact that the Microsoft patents don't
seem to impact any of our work.
(Note: I am separately pushing for a patent cross-license
agreement to handle such Open Source issues, so in a sense
this is a potential conflict-of-interest in that I have
non-spf reasons for wanting to ease any unnecessary patent
issues. The only reason I brought up this low-priority issue
is because of my dual reasons for wanting to solve the patent
issue.)
o Help those who are really doing all the implementation and
coding work by staying out of their way and making things
easier for them. (Basically useful best-current-practices
documents to help folks not repeat each other's mistakes,
good links on our site, etc.)
o Draft Wayne back into the council. (Is this allowed? :-) )
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com