On 02/12/2006 17:36, Frank Ellermann wrote:
Alex van den Bogaerdt wrote:
I am afraid that this is going to cause the same record to be
processed different by different receivers.
For new modifiers that's the case, and therefore new modifiers
should be aware of this. As explained in the "options"-draft,
a shorthand for a simple kind of YES- or NO-modifier.
Ignoring op=pra for the moment (= until the IAB decision) the
most interesting proposal was Scott's idea for something like
op=dkim indicating a STRONG DKIM signing policy:
If receivers don't know this modifier / option, they'll simply
ignore it. If they don't support DKIM they'll simply ignore
it. If they don't like this option / modifier they'll simply
ignore it.
But if they know _and_ like _and_ support it, they can abort
the evaluation of the sender policy, wait for the DATA, check
it for a valid DKIM signature, and reject the mail otherwise.
Actually what I think I'd suggested is using op=dkim after an SPF Fail as yet
another method for solving the forwarding problem. This one has the
advantages of not requiring forwarders to change anything.
So op=dkim would essentially be a plea from the sender to go to DATA and see
if you get a good DKIM signature and accept based on that rather than reject
based on SPF FAIL.
Advantage: It works even behind clueless 5.3.6(a) forwarding.
It's about the weirdest way to address this issue, but it does
work, and I think it's very attractive for domains like Paypal
or any other domain with a STRONG DKIM signing policy.
...
P.S.: The problem with op=dkim and other future modifiers is,
that checkhost() as specified has no way to report results in
addition to pass / fail (exp) / ? / ~ / permerror / temperror.
A bit more than only an "implementatiuon detail" unfortunately.
The modifier would have to be process after checkhost() returns a FAIL. At
that time the SPF record is in the local cache, and so pulling it in again
for higher level processing is fast and cheap.
Any multi-technology anti-forgery program is going to have to decide how to
combine results and this gives the receiver a clue on how the sender suggests
they proceed.
Additionally, a related suggestion I had was op=from (specifying that Mail
From and From should always be the same). This would be a cheap and easy way
for highly phished domains to leverage SPF into the From domain. It breaks
mailing lists and other applications, but some domains would be willing to do
that.
You could even combine the two, op=from=dkim so that if From and Mail From are
different, only accept the message if the From domain gave the message a good
DKIM signature.
There may also be things we could do with scoping HELO like op=helo (this
domain is only used for HELO, so you don't even have to process the record if
it's in Mail From) or op=nothelo (this domain is NOT used as a HELO, so if
it's used that way you don't even have to process the record). Now those are
just optimizations, but they may be of some benifit.
None of this changes the SPF result, just gives some additional guidance on
how to relate to other technologies/identities.
Scott K
-------
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/?listname=spf-discuss(_at_)v2(_dot_)listbox(_dot_)com