On Thu, Nov 13, 2003 at 12:49:39PM -0500, Meng Weng Wong wrote:
|
| Just a heads-up: the draft is still changing a tiny bit, becoming even
| simpler.
The work-in-progress draft is at
http://spf.pobox.com/draft-mengwong-spf-02.6.txt
If anyone has Hydra/SubEthaEdit and would like to help clean up the
sticky bits, join me at
hydra://ibook.icgroup.com/draft-mengwong-spf-02.7.txt?documentId=9417B9CA-15FC-11D8-B17B-000A95A03948
Read on for a summary of changes.
* * *
Eric Allman read the 02 draft. "Good idea, but why so baroque?"
So Mark Lentczner and I spent Sunday afternoon on a sofa, me with my 12"
and him with his 15". Mark is a very experienced, very smart protocol
designer; his last trick was writing a full-fledged next-generation web
server from scratch in about two months. His aesthetic sensibilities
are far more evolved than mine, and are sure to better please the fine
people on this list.
1) The scope modifier is going away.
The idea behind scope=header-from,envelope was to block
service(_at_)paypal(_dot_)com forgeries. But it turns out to be easier to
implement this as a mechanism that simply requires the header from to
match the envelope. Since nobody has actually asked for this, maybe
it'll never get used! We're going to make it optional.
2) The "default=deny" modifier has turned into the "all" mechanism.
Mechanisms are booleans: match or no-match. When there is no match,
processing continues. When there is a match, the mechanism prefix
is the result value. "All" is a mechanism that always matches, so it
is effectively the default.
before: "v=spf1 a mx default=deny"
after: "v=spf1 a mx -all"
3) The shorthands have changed.
before after means
------ ----- --------------------------
? ? unknown
+ + allow aka pass
- ~ softdeny aka softfail
! - deny aka fail
- is the natural opposite of +. ~ is a soft minus.
When omitted, the default shorthand is now "+".
4) The "exec" mechanism has turned into a "redirect" modifier.
There should never be more than one redirect per directive-set.
Other mechanisms are still free to run, but if nothing matches, the
redirect will apply.
"v=spf1 redirect=example.org"
The typical redirect case has no mechanisms anyway.
5) The explanation modifier has become a pointer to a TXT record.
Previously we had an "exp=please see http://..."; modifier.
People were unhappy with this because the spaces meant it had to go
at the end. We could have used %_ to escape spaces, but that would
have loooked yucky. How did we solve the problem? By adding another
layer of indirection.
domain.com "v=spf1 -all exp=exp._spf.domain.com"
exp._spf.domain.com "Mail from %d must come through designated hosts."
6) Unrecognized mechanisms now short-circuit to "unknown".
Unrecognized modifiers are ignored.
Mechanisms look like /\w(:\S+)?/
Modifiers look like /\w=(\S+)?/
7) The "reports" extension mechanism is now the "reports=yes" modifer.
8) The draft may fission into two, separating the policy gramar from
the designated sender scheme.
SPF is two things:
- a grammar for domains to publish arbitrary policies, and
- a set of definitions that describe a designated sender scheme
as one possible policy.
If they wanted, people could also publish other kinds of policy
statements:
"v=spf1 habeas -all"
Check the headers for a Habeas haiku. If there is no haiku, deny.
If the SPF client doesn't understand Habeas, result is "unknown".
"v=spf1 a mx ptr smime:pubkey._spf.%{d} -all"
If the message doesn't come from a designated sender host, maybe the
body is still good; check the signature using a public key available
by TXT at pubkey._spf.domain.com. This is effectively
designated sender || smime || fail
It will be interpreted correctly by SPF client libs that understand
both DS and SMIME.
It will also be interpreted correctly by SPF client libs that only
understand DS --- when they hit the "smime" they will return unknown.
Mail::SPF::Query will probably set the Received-SPF header to
something like
Received-SPF: unknown smime:pubkey._spf.domain.com (domain of
XX(_at_)domain(_dot_)com uses unrecognized mechanisms)
And then a downstream entity could do the SMIME check for validity.
This imposes the burden of DATA on SMTP receivers, but is the only
100% backward-compatible solution to .forwards.
We are getting into IANA issues here: we'll need a registry of
extension mechanisms.
* * *
This is the new table of contents.
Table of Contents
1. Introduction
2. SPF Records
2.1 Publishing
2.1.1 DNS TXT record
2.1.2 DNS location
2.1.3 Ancillary information
2.2 Querying
2.2.1 Current Domain
3 Interpretation
Matching Version
Checking Mechanisms
Unrecognized Mechanisms
Default result
Redirected Query
Explanation
The Received-SPF header
4. Basic Mechanisms
'all'
'include'
5. Designated Sender Mechanisms
4.1 'a'
4.2 'mx'
4.3 'ptr'
4.4 'ip4' and 'ip6'
4.5 Arguments
4.5.1 Domain
4.5.2 CIDR Lengths
6. RBL Style Mechanism
5.1 'exists'
7. Misc
4.1 Macros
4.2 URL Encoding
8. Received-SPF header
Appendix A: Collected BNF
Appendix B: Extended Examples
-------
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.txt
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to
http://v2.listbox.com/member/?listname(_at_)©#«Mo\¯HÝÜîU;±¤Ö¤Íµø?¡