On Sat, 2 Dec 2006, Julian Mehnle wrote:
Look, the problem is that everytime this comes up, after a while I get
tired debating it, but it always comes up again later because I just can't
get this "Pass means I authorized the message, but don't blame me for it!"
concept into my head. It doesn't make sense to me. Not. Make. Sense. To.
Me. :-(
A Modest Proposal: Intensifiers for SPF Results
We should introduce the '*' character as an "intensifier" to mean
"I really mean it". So, for example, the policy:
"spf3.14 ip4:1.2.3.4 *-all"
says FAIL, and I REALLY MEAN FAIL, if the connect ip is not 1.2.3.4.
This applies to any result. For instance:
"spf3.14 *A:my.mailhost.com -all"
Says that mail gets PASS when it comes from my.mailhost.com, AND I REALLY
MEAN PASS.
The beauty of this system is that it can applied iteratively. When people
are still afraid to reject forged mail with a *FAIL result, because you
didn't mean it enough, you can up the ante by just adding another '*':
"spf3.14 ip4:1.2.3.4 **-all"
says FAIL, and I REALLY, REALLY MEAN FAIL, if the connect ip is not 1.2.3.4.
For checking implementations, this means that results are numbers.
When "***-all" matches, the result is FAIL*4 (the first "really" is
implied), or "FAIL, and I REALLY, REALLY, REALLY MEAN IT".
As time goes on, and the need to up the ante escalates, all those '*'
characters will start to eat up precious DNS packet space. So to
help keep things in the UDP realm, an infix '*' with a decimal constant
can be used as a shortcut for multiple intensifiers. For example:
"spf3.14 ip4:1.2.3.4 -*7all" is equivalent to
"spf3.14 ip4:1.2.3.4 ******-all" or
"FAIL, and I REALLY, REALLY, REALLY, REALLY, REALLY, REALLY MEAN FAIL!"
The advantages of this simple extension should be obvious to all. It
accommodates whose who feel the need to express the precise level of
their commitment to an SPF result, without the need to continually add
new result codes to the SPF standard.
When reporting an intensified SPF result in the Received-SPF header,
the *n notation should be used. For instance,
Received-SPF: pass*5 (mail.example.com: the foobar.com domain has designated
1.2.3.4 as a permitted sender, and they REALLY, REALLY, REALLY, REALLY
MEAN it) client-ip-1.2.3.4; envelope-from=user(_at_)foobar(_dot_)com;
helo=mail.foobar.com; identity=mailfrom; receiver=mail.example.com;
When comparing intensified SPF results, intensity MUST be considered
only when comparing results with the same base result.
So, for instance, FAIL*1 is more not permitted than SOFTFAIL*1000, or
any other intensity for SOFTFAIL. And NEUTRAL*1000 is not more permitted
than PASS*1.
Intense SPF implementations SHOULD use arbitrary precision integers to
represent result intensity. Otherwise, escalating intensity bidding
wars may quickly overflow any fixed precision. If a policy does overflow
a checking implementations fixed precision, the receiver SHOULD act as if
no policy was present (or that they never fetched it).
--
Stuart D. Gathman <stuart(_at_)bmsi(_dot_)com>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flammis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.
-------
Sender Policy Framework: http://www.openspf.org/
Archives at http://archives.listbox.com/spf-discuss/current/
To unsubscribe, change your address, or temporarily deactivate your
subscription,
please go to http://v2.listbox.com/member/?list_id=735