(Ever keep putting off saying "send" for days because an email just
doesn't quite fit? Anyway...)
A few days ago I suggested a way of extending the spf syntax with an
explicit extension mechanism "x". (It's in the archives at
http://archives.listbox.com/spf-discuss(_at_)v2(_dot_)listbox(_dot_)com/200401/1449.html
)
It was basically a suggestion for an "x" mechanism to act as a wrapper
for nonstandard mechanisms. Clients that recognized the enclosed
extensions would act accordingly, and clients that didn't would be able
to look at the "x" mechanism itself to see what to do.
(In other words, an unrecognized mechanism wouldn't have to result in an
"unknown" answer, and as a side effect of all this, the extension
mechanism "x" allowed for "and"s and "or"s in spf descriptions, although
in a somewhat awkward manner.)
Although I still think something like the "x" extension would be useful,
over the last few days as the topic of extensions came up again (or as
previous threads have continued--I'm not sure really which), I've
realized that the "x" mechanism by itself isn't...extensible enough to
account for everything people have been talking about. (Well, not
without jumping through more hoops within the wrapped, undefined
mechanism.)
The reason it's not enough is that folks are bringing up two
possibilities:
1. The possibility of needing to meet multiple requirements
to pass a specific test. For instance, requiring an email
to be sent from certain IP's *and* something-else-mumble-mumble.
(Yes, it could be done within the subtest of the "x" extension.)
2. The possibility of having more than just spf-type requirements
specified in spf records. (ie, the authorization vs. accreditation
vs. reputation threads.)
The easiest way to resolve (1) would be to allow for a point-scoring
system, and the easiest way to resolve (2) would be to allow for more
than one dimension of scoring.
Modifying the spf spec to allow for multidimensional point scoring, with
the published spf strings defining what score you'd have to reach to
achieve SOFTFAIL or PASS for each dimension is....extreme to say the
least!
However, while such modifications to the spec for actual production use
would be extreme, an imagined modification for the purpose of thought
experiments isn't so extreme, and I think it can help in thinking more
clearly about extensibility.
(For instance, I think it's easy to get confused when you don't realize
you're trying to put a second dimension of information into one
dimension of an answer. Being able to notate your actual ideas makes it
easier to figure out if it's a good idea or not--regardless of whether
the idea should or should not be put into some future spf version in
some form.)
So, here are the changes:
-------------------------
1. "+" and "-" are replaced by (points, dimension).
So "+a" would be replaced by (+infinity,spf).
This would allow for "(+2,spf)mx", for instance.
2. Allow for multiple point-definitions before any mechanism.
So: "(+2,spf)(+3,example.com/accred)a" would mean
that if the sender was from an A record of the domain,
not only would the spf score increase by 2, the
accred score as defined by example.com is increased by 3.
3. Add a "limits" modifier.
limits=(spf,2,5),(example.com/accred,3,7)
This means that an "spf" score below 2 should be interpreted
as a FAIL, a score of 2,3,4 interpreted as "SOFTFAIL", and
a score of 5 or above as "PASS".
An example.com/accred score below 3 should be interpreted
as FAIL, a score of 3,4,5,6 interpreted as "SOFTFAIL", and
7 or above as "PASS".
4. Add an "x" extension modifier:
(0,spf)(-1,example.com/accred)x:(test):(scores)new-mech-goes-here.
Clients would run the test. If it doesn't pass all included scores,
then skip. If it does pass, then clients that don't understand
the new mechanism would modify the scores as to the left of the "x",
(In this case, don't change the spf score and subtract one from the
example.com/accred score.) Clients that do understand the new
mechanism would run the new mechanism and modify scores as described
in (scores).
Another example:
(0,spf)(+5,example.com/blah)x:(+all):(+1,spf)example.com/pgp:foo
Would mean that clients that understood the example.com/pgp
mechanism would add 1 to the spf score if that mechanism test
passed, and clients that didn't understand it would leave the
spf score unchanged and would add 5 to the example.com/blah
score.
5. The "Received-SPF:" would have to list the different
scores, listing "spf:pass" instead of "pass".
6. Scores not written to during evaluation would default to
"unknown". Except for the "spf" score, unknown scores
would not be written into the "Received-SPF" header.
7. You could also define defaults for backwards compatibility
with existing published strings, so that, say, "+a" would be
interpreted as "(+infinity,spf)a", and any results of positive or
negative infinity would cause the client to lock in the value of
that score throughout the rest of the string.
I think imagining the spec being modified with those sorts of changes
can help in thinking about extending the spec with more mechanisms and
modifiers.
(Reading back over this, it looks like I'm some spf-crazed D&D fan:
"It'll be so much easier to send out emails with my new +5spf mace!")
--
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.7.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;±¤Ö¤Íµø?¡