In
<2A1D4C86842EE14CA9BC80474919782E0356EF98(_at_)mou1wnexm02(_dot_)vcorp(_dot_)ad(_dot_)vrsn(_dot_)com>
"Hallam-Baker, Phillip" <pbaker(_at_)verisign(_dot_)com> writes:
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.
Agreed.
Fortunately I think that the extension mechanism works. The key is that you
use modifiers for pretty much any type of modification.
YES! YES! YES!
I've been saying that for a while now.
If you only want to use the new scheme:
v=spf1 domainsig=always +all
Was this supposed to be -all?
If not, I think I'm unclear on something.
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.
I disagree on this point.
The SPF result should not be changed by a modifier. However, the SPF
result should not and will never be the final word on whether
an email is rejected or accepted.
So, say we have "v=spf1 mx -all fredsnewtest=<blah>"
if the email passes the fredsnewtest, the SPF result might be "fail", but
the fredsnewtest result would be "pass". A system that understands
this new test could add headers such as:
Received-FredsNewTest: pass override-spf-result=yes
Received-SPF: fail <......>
-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.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;±¤Ö¤Íµø?¡