On Thu, Jan 29, 2004 at 03:54:23PM +0000, Wechsler wrote:
| What follows is the view from where I stand. Please comment.
Thanks for the excellent roundup, Wechsler. I can't think of a better way to
start the day.
| Problems (finality):
|
| * We have a frozen specification but no clear definition of what that
| means. We need to know that.
I'm readying the draft for submission to the ID archive. It's going to
attract a lot more eyeballs then so I want to make sure everything's
internally consistent. Also, as my recent post re envelope / headers
shows, I want to be able to support as many stories as possible. SPF
started out as an envelope-only thing but if you just put on another
pair of glasses you can say "hey, it works for headers too".
|
| * 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.
|
We can turn this over to IANA once the draft is done.
| * 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.
I just spent some time on this. This is a relatively big change that
clarifies a lot of things. In practice I estimate this means about 20
minutes of work for a library author. This grows out of the critique by
Bellovin and the thinking by Philip Gladstone.
3 Interpretation
When an SPF client evaluates a domain's SPF policy, this evaluation
produces one of seven results:
None: The domain does not publish SPF data.
Neutral (?): The SPF client MUST proceed as if a domain did not
publish SPF data. This result occurs if the domain explicitly
specifies a "?" value, or if processing "falls off the end" of
the SPF record.
Pass (+): the message meets the publishing domain's definition of
legitimacy. MTAs proceed to apply local policy and MAY accept or
reject the message accordingly.
Fail (-): the message does not meet a domain's definition of
legitimacy. MTAs MAY reject the message using a permanent
failure reply code. (Code 550 is RECOMMENDED. See RFC2821 [11]
section 7.1)
Softfail (~): the message does not meet a domain's strict
definition of legitimacy, but the domain cannot confidently state
that the message is a forgery. MTAs SHOULD accept the message
but MAY subject it to a higher transaction cost, deeper scrutiny,
or an unfavourable score in a rule-based system.
There are two error conditions, one temporary and one permanent.
Error: indicates an error during lookup; an MTA MAY reject the
message using a transient failure code, such as 450.
Unknown: indicates incomplete processing: an MTA MUST proceed as
if a domain did not publish SPF data.
So what used to be "unknown" has now been broken out into
"unknown-as-error" and "neutral-as-explicitly-defined".
You end up with the same behaviour but you can speak more accurately
about the semantics.
And we bring back softfail because I really think AOL should be doing
~all and not ?all. Of all the ISPs in the world they probably have the
most tightly constrained userbase, and can say with the most confidence
that if it's not coming through an AOL server, it's not really an AOL
user. Correct me if I'm wrong.
|
| 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.
|
The challenge is picking out the correct IP. Maybe the author of
SpamBouncer can help.
-------
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;±¤Ö¤Íµø?¡