On Thu, 3 Mar 2005, Martin G. Diehl wrote:
Chuck Mead wrote:
I have several thoughts about this.
1. We do not have rights to make changes to the web site right now.
Who does? There are some errors that need to be corrected.
Meng does, but he seems to be refusing to change anything, purposely or
not is not quite clear right now (he certainly does have some bias and
probably wants to keep SenderID page and other things that people here
have complained most about).
3. I think SPF deserves its own domain name instead of riding as a
sub-domain of pobox.com.
Yes. And we talked about it long time ago before council was formed
and even discussed possible domain names. Most agreed that openspf.org
as offered by James Couzens was best one and recently JohnP offered
the .com/.net domains that he registered after that discussion, so
SPF can either have all of .com/.net/.org which is good. We can this
all again in public or SPF Council can do it, but please decide on
this fast. The domain(s) themselve would have to be transfered/registered
to SPF Project and controlled by spf council (administrator probably
chair of the spf council), at least that is what I suggest.
That seems correct. OTOH, what to do about the existing and
already deployed SPF code that has an embedded URL that links to
spf.pobox.com?
I would say that the appropriate thing to do would be for SPF Council
to issue an official resolution request to Meng to redirect current pages
to new website when its ready. This should be a "temporary" redirect for
one year with option to request additional year extension(s) after that
if necessary and if too many people are still heating old site.
4. A lot of people have ideas. This is a good thing
[snip]
people have suggested a custom interface be built.
Uhm... I only have one question about that... why the hell
is it that everytime a net based, geek driven project
decides to update their web site they start discussing
development of new custom interfaces?
I would recommend a server-driven CMS with options for multiple editors
to to work on different pages that can then be linked together. There
is a good list & comparison of various cms packages available at
http://www.cmsmatrix.org. Choosing best one is up to the council.
Personally I would recommend tikipro, but I'm biased as I'm one
of the developers of that cms :)
How many geeks do you know who don't like to write code?
... and if they stop, they get banned from the club.
To what end... and more over... who gives a crap? I could
take Mambo and build us a perfectly comfortable site in a
day. Others here could take their favorite CMS and do the
same.
Yes, that would be violating this wise rule ...
Don't let the perfect become the enemy of the good.
--Cariadoc's Maxim
So... what I propose we do is register a domain for spf and
then get it hosted somewhere on a CMS that several of our
number are familiar with and able to template and manage.
Thoughts?
Other suggestions?
(1) We want the information there to be
(a) available,
(b) visible, and
(c) accurate.
Can you take 2 out of 3? (just kidding :)
For what it's worth, I suggest the use of static web pages
that will work on *all* browsers. ... and all readers, even
including those who signed up for their first screen name
some time yesterday.
There are many cvs (especially simple wiki based) that will provide
results in simple html compatible with ever browser, even if server
side runs more complex code (note: tikipro is NOT one of those cms...)
The idea is to have them on our side ab initio --
Not to 'win' them back later; NOT to talk down to them.
Categories ...
(A) Lucid, plain language explanations of
SPF; eMail, eMail routing, forged headers; phishing, ...
and the use of special keys such as 'Shift' and 'Del'.
I could suggest including proper eMail and Usenet reply
and quoting style ... but I don't want to start a
religious war ... at least not here. <g>
Quoting style is not as important as you may think to most users,
there are very few zealots.
(B) Lucid, plain language explanations with pro AND con
commentary for each of the various pending alternatives,
Domain Keys, eMail 2000, MS Sender ID framework,
whitelists, blacklists, open relay blacklists, ...
Don't make it sound like alternatives. You want to make it clear
that SPF works on its own and cryptographic also works on their
own but their are not alternatives as they protect different layers
and work in different ways. Dont sepdnt oo much on this either,
the webpage should be about spf.
(C) References to the governing documents; and to each of
the discussion forums that are working on revisions and
new designs.
Good. This should be easy to find, not like on the current spf.pobox.com
page.
(D) A FAQ about the ongoing development: must have links to
the current drafts and and relevant standards.
Combine with (C) possibly.
(E) I suggest keeping all discussions eMail based (non-HTML,
if at all possible) -- IOW, no change from what we have now.
If we need to nitpick a document, we could use specific
tags in the subject ... e.g. [DRAFT], [COMMENT SPF ver]
[REVISED SPF ver+1] ... They stand out and can be used
as incoming filter rules.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net