Sorry to return to this yet again. I think I have worked out how to express
the semantics necessary if SPF is extended.
The reason why I have been considering this so importantly is that it really
does not matter if you deploy something that turns out to be broken in an
unexpected way provided it can be extended to fix it. Getting the extension
mechanism right is the one thing that really stands in the way of declaring
1.0 IMNSHO.
Fortunately I think that the extension mechanism works. The key is that you
use modifiers for pretty much any type of modification.
The test cases for an extension mechanism are
1) Completely new syntax (XML, S-Expressions, anything)
Can the new syntax be confused with the old?
2) New description mechanism (e.g. accreditation)
3) New authentication mechanism
Is phased introduction possible?
Sender uses new authentication mechanism as supplement
Must not have messages rejected by legacy filters
Must be able to state new mechanism always present
Sender uses new authentication mechanism as replacement
Must not have messages rejected by legacy filters
Must be able to state new mechanism always present
The solutions are as follows:
1) Use a new SPF version identifier.
We can have up to 9 new identifiers without changing the current scheme.
2) Use a modifier - that is what they are for.
accreditation=accredit.example.com
3) Use a modifier as follows
domainsig=never authentication extension is never used,
if you understand the extension reject messages carrying it
domainsig=always authentication extension is always used,
if you understand the extension reject messages not carrying it
domainsig=request authentication extension is used on request,
if you understand the extension and you request it,
reject messages not carrying it
domainsig=some authentication extension is sometimes used
OK so if you want to use IP authentication and the new scheme you would
state:
v=spf1 +mx domainsig=always -all
IE if you understand domainsig AND you support it you would reject
email that failled either the mx or the domainsig test
If you only want to use the new scheme:
v=spf1 domainsig=always +all
The 'request mechanism' does not have to be specified, I would expect it
would be a similar DNS scheme to SPF. But it is possible to say the new
scheme is used on request, otherwise basic SPF is used:
v=spf1 +mx domainsig=request -all
The only change to the spec would be to state that modifiers may change the
criteria for evaluating SPF directives in a client that supports that
specific modifier.
The part we are missing is the extension model for the modifiers. At the
moment we have a registry type approach. I think that will probably be
sufficient. It worked on UUCP for years until they got to thousands of
hosts. I would not anticipate more than a handful of modifiers.
Phill
-------
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.5.txt
Wiki: http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡