Scott Kitterman wrote:
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.
Yes. Most other SPF results normally don't result in "reject",
so it's kind of pointless to evaluate the policy if only an
evaluated FAIL is deferred to DKIM.
The reeceiver could as well assume "conditional FAIL" without
wasting time for the SPF evaluation, and later spend this time
to evaluate DKIM, and then without valid DKIM signature reject.
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.
Maybe there are two relevant cases: What I proposed, that's an
accelerator for STRONG DKIM policies. "Ignore SPF if you like,
you can reject anything without valid DKIM signature, because I
sign all _my_ mails".
That still needs work, the concept of "my mail" in v=spf1 and
in DKIM is rather different... <sigh /> It's also different
from PRA: <http://permalink.gmane.org/gmane.ietf.dkim/2178>
What you originally proposed was "try also DKIM if you can
in the case of a FAIL" (maybe also SOFTFAIL if it's rejected).
For that it's not necessary to have a STRONG signing policy.
That's a delayed 'reject' asking receivers to evaluate both
SPF and DKIM before they 'reject'. It has the same problem
of different definitions for "my mail", v=spf1 uses MAIL FROM.
For DKIM I'm not sure what the state of the art is, maybe it
is "the first address in the 2822-From" (better check this).
So maybe we want different options strong-dkim and weak-dkim
with different semantics. It's pointless to have both in the
same SPF policy ;-)
We can also define a separate dkim= modifier with two values,
either strong or weak. and adopt some general considerations
for new SPF modifiers from the options-draft, it's not much
but IMO important (for questions about modifiers like Alex'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.
Okay. That recipe (or hack ;-) would work for both "weak" and
"strong" - the latter could simply signal FAIL without actually
evaluating the policy. And if an SPF implementation evaluates
the policy in presence of "strong" it only wasted some time, no
harm done.
So your proposal is:
1a - evaluate policy with check_host() as implemented, a "dumb"
check_host() doesn't know that "strong" is an accelerator,
but that's no real problem.
1b - note check_host() result but don't act on it in this step.
2 - scan policy again for "interesting" options / modifiers,
and even in the worst ten-nested-include case this scan
finds all relevant info in the cache.
3a - if nothing "interesting" is found act on the result noted
in step 1b, and continue with the SMTP session
3b - otherwise "modify" the noted resulted into a flag for the
DATA-processing, and continue with the the SMTP session.
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.
Yes. But the second of the about three steps, the scan for new
"interesting" modifiers, belongs to a "modified" SPF processing.
Maybe "smart" implementations could combine 1a, 1b, and 2 (?)
a related suggestion I had was op=from (specifying that Mail
From and From should always be the same).
That would answer any issues with the definition of "my mail".
Does it also have any technical meaning for receivers ? What
are they expected to do with it ?
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.
Is that op=strong.from or op=weak.from ? I don't get your
point, we need one of Hector's tables:
v=spf1 MAIL FROM DKIM valid DKIM invalid DKIM missing
PASS + From equal accept ? accept
PASS + From different ? ? ?
n/a + From equal accept ? ?
n/a + From different ? ? ?
FAIL + From equal ? reject reject
FAIL + From different ? reject reject
Cases where the "DKIM invalid" and "DKIM missing" outcomes are
different would be critical. What about the eleven "?" cases ?
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)
At the moment op=helo stands for "treat anything but a PASS for
HELO like FAIL". Your idea could be a new op=nomail (if you're
checking MAIL FROM exit with FAIL).
op=nothelo (this domain is NOT used as a HELO
Yes, I have that as op=nohelo, "If you're checking HELO exit
with FAIL, this domain isn't used as HELO identity". A quite
common case.
None of this changes the SPF result
It does, and that's the naive idea of a modifier, it modifies
the SPF result, op=nohelo means "FAIL for HELO no matter what".
A new op=nomail would be "always FAIL for MAIL FROM". But IMO
it's unnecessary: The typical "v=spf1 a -all" policy used for
HELO-only-FQDNs has almost the same effect. The sender will
be able to avoid using this FQDN in MAIL FROM sent from his A
directly, he doesn't need the help of receivers for this task.
Bye, Frank
-------
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