On Thu, 2004-01-29 at 20:13, Julian Mehnle wrote:
Meng Weng Wong [mengwong(_at_)dumbo(_dot_)pobox(_dot_)com] wrote:
Sites that don't wish to support it will return an "unknown" and
proceed with spamfiltering.
The use of undefined mechanisms should be explicitly discouraged,
i.e. forbidden in a technical sense. If Joe Average starts publishing
SPF records with undefined mechanisms (potentially useful, as Joe
thinks), more and more SPF checks will return "unknown", and SPF will
grow increasingly useless. This might undermine the global value of
SPF.
Right now in-spec clients return "unknown" for undefined mechanisms and
ignore undefined modifiers, leaving only two choices for folks
interested in publishing records with undefined extensions.
I wish I had subscribed long ago. After writing the whole
pgp-within-modifier example earlier today, (workable, but somewhat
unwieldy), and coming back to your message here, I just realized you
could have a syntax that would possibly answer concerns along your line
in more detail.
It would have been nice to have an "extension" mechanism, say "x". For
instance:
+x:(+all)+pgp:foo # Strict clients return pass
-x:(+all)+pgp:foo # Strict clients return fail
~x:(+all)+pgp:foo # Strict clients return softfail
?x:(+all)+pgp:foo # Strict clients return unknown
$x:(+all)+pgp:foo # Strict clients ignore/skip this mechanism
Non-strict clients recognizing pgp would return "+" if the pgp extension
matched.
However, all clients would first evaluate the expression within (), and
ignore the whole mechanism if it didn't match. (Presumably, "exists"
mechanisms would work really well in the "()" spot.)
I think this would answer many objections. At least people publishing
extensions would have to be explicit on what they wanted in-spec clients
to do.
(As an aside, this sort of syntax could also let you do boolean ANDs in
strict clients--if the undefined extension were really a defined
extension, then you could say the equivalent of +"exists:blah AND mx".)
Maybe something along these lines could be an spf2 thing if it turned
out this sort of extensibility was needed or strongly desired.
--
Mark Shewmaker
mark(_at_)primefactor(_dot_)com
-------
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;±¤Ö¤Íµø?¡