In <40192CAF(_dot_)8010401(_at_)phase(_dot_)org> Wechsler
<wechsler(_at_)phase(_dot_)org> writes:
What follows is the view from where I stand. Please comment.
Knowns: [snipped]
Agreed on all of those
Problems (finality):
["slushy" spec, clamouring to get changes in before finalization, etc.]
I agree that this is a problem. I don't think this is a problem that
will ever fully go away. Every spec/standard can be changed if enough
people want it and if enough people think it is worth the change.
I think we are still learning stuff from implementing, testing and
deploying the SPF spec and I think there are things that need to be
changed based on that.
With every passing day, there will be more people who publish SPF
records or deploy SPF checks in MTAs. As a result, any changes will
be more costly to the installed base and less likely to be worth
while. Changes that are incompatible are unlikely to be made right
now, but changes that only effect corner cases or resolve ambiguity
are still probably worth while.
Extensibility:
* http://spf.pobox.com/mechanisms.html states that third party
* mechanisms and modifiers are permitted.
I think that web page is out of date, ambigous and wasn't even brought
up to date with the "frozen" spec that came out in Dec. I would say
that that right now, the definative sources of info are the draft
standard and the perl implementation of SPF. Differences between
these two need to be resolved ASAP as should differences with other
implementations. After we have learned all that we reasonably can
from implementing SPF, the spec has to become the controlling
document, not the code and not web pages.
Politics
* Meng (and probably others) is/are putting incredible effort into
* ensuring that SPF is properly understood and appreciated by the big
* players.
This politicing has also been very time consuming and destracting. It
might have been worth while, but it has had costs.
* Merging with another standard MAY provide a need to modify the
* syntax of either SPF or a subsequent protocol, but we have, as yet,
* no concrete ideas on what those standards might be, or the timescale
* for merging.
I think Meng has seen and read most of these other proposed
standards.
From what I know of DomainKeys, it is a non-starter. It breaks huge
amounts of stuff compared with SPF, is far more expensive than SPF,
it doesn't solve any problems that SPF doesn't, and it doesn't have an
installed base that competes with SPF. DomainKeys should be written
off, although maybe other ideas of using public-key stuff would be
useful.
MS Caller-ID addresses a slightly different issue than SPF and is in
some ways compatible. MS could rip out a few parts of Caller-ID (the
XML in DNS stuff) and use SPF instead. It would then be an ok (but
not great) spec for verifying email headers. I think a far better
spec could be written, but if MS is willing to put Caller-ID (with XML
replaced with SPF) into all of their email systems, then I would be
quite happy with it.
Personalities and Flux
I suspect that many of use would do well to reread spf.pobox.com and
spfwiki.infinitepenguins.net . Both Meng and I would do particularly
well out of people doing this as you can tell us if we've written
anything there that now appears to be outdated or based on
misconception.
Before reading the websites, read the latest SPF spec draft.
Work needed:
* 'Perfection' of SPF-MTA patches and code libs
* Advocacy
* Examination and critique of SRS
* SRS patches for all major MTAs
* Testing
Swap the ordering of "testing" and "advocacy" around. We don't need
more advocacy right now, we need to make sure what we have is right.
-wayne
-------
Sender Permitted From: http://spf.pobox.com/
Archives at http://archives.listbox.com/spf-discuss/current/
Latest draft at http://spf.pobox.com/draft-mengwong-spf-02.9.4.txt
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡