What follows is the view from where I stand. Please comment.
Knowns:
* We have over 5300 SPF records active and in the wild.
* These are already helping in the identification of both spoofed and
valid messages.
* We have some significant users among the early adopters:
http://www.infinitepenguins.net/SPF/earlyadopters.php
* A recent upsurge in Joe-Jobbing and virus activity has reminded
everyone (even if they've never heard of SPF) of why source
authentication is required.
* We currently have a version of SPF that *works for now*, at least.
* SPF patches to MTAs are maturing rapidly.
* SPF can be deployed on a softfail basis prior to a worldwide
forwarding fix without risk to mail transmission.
* We have two sites of fairly high-grade documentation which are
starting to be translated into other languages.
Problems (finality):
* We have a frozen specification but no clear definition of what that
means. We need to know that.
* The pending "finalisation" means that everyone who feels that
additions are needed prior to v1-final is clamouring to get these
changes in, in the unknown timescale prior to finalisation.
* There is disagreement on what constitutes a modification to the spf1
standard and what changes would require incrementing of the version number.
* Adding mechanisms and modifiers falls within the remit of
extensibility. Removing them from a v1 spec does not.
Extensibility:
* http://spf.pobox.com/mechanisms.html states that third party
mechanisms and modifiers are permitted.
* Unknown mechanisms will cause 'unknown' results IF the parsing of an
SPF record gets that far without reaching a result.
This is a defined and accepted behaviour of the specification.
* 'PGP' and 'Habeas' are proposed as mechanisms (but have undefined
syntax as yet). Therefore we can imagine an example of:
v=spf1 +a/24 +mx +pgp -all
In the normal case, mail will be sent from the home /24 subnet or the
home mailserver (perhaps via SMTP auth). The domain owner undertakes to
sign mail sent from any other location with a PGP signature. The default
is -all as we assume that this example takes place in the happy shiny
future when SRS is implemented widely.
I believe that the behaviour of both pgp-aware and non-pgp-aware SPF
agents in handling this record is fully acceptable.
* The extent of wishing to integrate 'reputation' into SPF goes only as
far as creating SPF mechanism names for them so that they can be
referred to by suitably aware MTAs.
Eg; introducing the string 'domainkey' into an SPF record serves only as
advice to MTAs; it does not constitute the integration of the whole
domainkeys specification into SPF.
* Unknown modifiers will be ignored and thus cannot be used to modify
the logic of the known mechanisms. They are best suited to informational
status, eg reporting and logging.
This is a defined and accepted behaviour of the specification.
* There is no central repository of new mechanisms / modifiers. This may
or may not matter, but a central *discussion area* for their
determination would be of great use.
* Leaving aside the confusion over the status of '~' (tilde, for anyone
whose font makes them as unreadable as mine), there is no immediate and
apparent need to extend the *syntax* of SPF for the sake of SPF
functionality. Syntax change for interoperability is another matter.
* The defined behaviour of SPF with regard to new mechanisms makes it an
ideal, lightweight baseline solution that not only allows it to play
nicely with other protocols, but also helps those protocols to play
nicely with each other.
Politics
* Some big names like SPF. Some big names don't. Some have their own
agendas and some just haven't read the documents properly.
* Meng (and probably others) is/are putting incredible effort into
ensuring that SPF is properly understood and appreciated by the big players.
* Merging with another standard MAY provide a need to modify the syntax
of either SPF or a subsequent protocol, but we have, as yet, no concrete
ideas on what those standards might be, or the timescale for merging.
As such I strongly suggest that we propose a *finalised* spf for
merging, rather than keep it in flux for unknown time and purpose.
Personalities and Flux
* We are all in this together. Some of us have been working on SPF for
longer than others. Some of us are newer and have ideas that have
already been worked over. All of us will have a perception of SPF that
is slightly tainted by our own ideas, memories of earlier drafts, or
misconceptions.
I suspect that many of use would do well to reread spf.pobox.com and
spfwiki.infinitepenguins.net . Both Meng and I would do particularly
well out of people doing this as you can tell us if we've written
anything there that now appears to be outdated or based on
misconception. I know Meng has a lot more time to work on SPF than I do,
but as mentioned before he's pretty busy right now too (that said, I for
one know of no "errors" in pobox.com. And I know that I often have to
skim the discussion lists and may well miss something.
Just in case anyone thinks I'm blowing my own trumpet too much here: I
am just the scribe, not the dictator. I ask people to read the wiki not
in hopes of a Pulitzer but in order that any mistakes be spotted and
that it be improved. And furthermore I make no claim to be an expert on
email; I'm a general-purpose admin and web developer (and a dozen other
things if you believe my CV).
Work needed:
* 'Perfection' of SPF-MTA patches and code libs
* Advocacy
* Examination and critique of SRS
* SRS patches for all major MTAs
* Testing
Can one of the perl gurus knock up a filter that we can put into user
.procmailrc files and so on that adds Received-SPF lines? I'll make a
seperate post on my version of this in a moment.
That'll do for now,
Wechsler
-------
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
Wiki:
http://spfwiki.infinitepenguins.net/pmwiki.php/SenderPermittedFrom/HomePage
To unsubscribe, change your address, or temporarily deactivate your subscription,
please go to http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡