On Fri, 2004-01-23 at 18:10, Meng Weng Wong wrote:
OK, the people have spoken. SPF v1 is frozen, and filtering will be
possible before DATA, unlike certain alternatives now under
consideration by the major ISPs.
Then let me be the evil guy who can publicly be tarred and feathered
because he brought up a question and suggestion after a (re)freeze..
spf1 was shown to be workable in practice, (in addition to looking
really great on paper), as people could write code, publish records, and
just see that, well, it really can work in practice. (Granted there's
still discussion on the SRS side of things.)
Eventually AOL even published spf records, and people were able to
report how many forgeries spf1 would have caught for them. So even
though the spec was theoretically potentially in flux, folks could
measure the effect of the currently proposed system.
But as spf1 becomes popular, everyone will be wanting to suggest all
sorts of additions and changes for spf2. Many of these suggestions,
(and most if not all of mine I'm sure), will be crap at at least some
level. However, people will tend to want to figure out how well these
new additions or changes would work in practice.
My question is: How should these tests be deployed?
I can't exactly publish an spf1 record on a production machine with a
new mechanism "coolfeature:yes" that I want to test out--that would
cause compliant clients to rightfully abort processing upon seeing an
unrecognized mechanism.
I see two possibilities:
1. People create TXT records beginning with "v=spf2", and write their
tests to look for that string, later changing their records to meet
the real spf2 standard when it's released.
Or perhaps they could create records with something like "v=spfnew",
given that no real spf spec will ever use the version "new" most
likely.
2. (Ducking) The spf1 standard could state that mechanisms beginning
with "ignore_me_" are to be ignored, and not cause spf processing to
abort.
That would mean that I could publish a record with
"ignore_me_coolfeature:yes ignore_me_somethingelse=1234" in an spf1
record, not break compatibility with spec'd clients, and folks who
were interested in one or the other or both could set their test
clients to enable the functionality of one or the other or both.
(You'd probably want something shorter than "ignore_me". Maybe
"local_", but I'd be afraid of potential spec fragmentation with
vendors all adding in additional "local" functionality.)
I'm thinking that (2) might make testing and future development easier.
However, even if the spec weren't frozen (I'm not sure if it's frozen
for such small tweaks--it probably is), (2) would add slight extra cpu
requirements for clients that could leave a bad taste in folks mouths to
have to have.
I realize that adding even minor complexity to the clients as (2) would
require would quite likely not be taken well at this stage--If so, I'm
fine with it being shot down and people just figuring out the best way
to do (1), but with the spec being frozen and the fact that people
sometime soon will want to test their favorite improvements or tweaks, I
figure if nothing else now is a good a time as any to ask how future
testing deployment should be done--then the discussion/answer can
already be documented in the archives by the time people are ready to
code their suggestions.
--
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.4.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡