On 02/12/2006 21:01, Frank Ellermann wrote:
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 flip side is that if I got an SPF PASS, I might not bother to check DKIM
unless they had an always sign, no 3rd party Sender Signing Policy (the
policy record for DKIM, for those not following that).
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.
Yes, but SPF is generally cheaper than DKIM and so, see above.
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".
Maybe even a pointer to the SSP to look that up first before firing off all
the DNS queries in check_host to see if the SSP is restrictive enough to
allow SPF to be bypassed.
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>
Right. I intend to stay away from PRA like a 10 foot pole. SPF and DKIM are
both reasonably implementable in both proprietary and free software. PRA is
more limited in it's applicability and so even if I thought it would work, I
don't think it's useful for internet scale problem solving.
Fortunately, for roughly 80% of the mail out there, the DKIM/SSP definition of
who is this message from matches the SPF definition. If we add op=from to
the mix, then we have a class of messages for which the domain owner has
stated they are the same. We do need to figure out what all this means for
those not able to say op=from and the 20%.
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.
It's targeted at providing yet another way to solve the "Forwarding problem".
It also has potential to be leveraged back to solve the DKIM "Mailing list
problem".
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).
I believe that's correct.
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 ;-)
Possibly.
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).
Yes.
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.
Proposal is probably too strong a word. It's an idea meant to be an example
along the lines of Hector's extensions and the type of problem I think we
should be focusing on right now. I think that productive work in this type
of framework is MUCH more important than a new SPF protocol version.
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.
Sure. Any modifier would require modified processing, but has to leave the
basic SPF result undamaged. This one is not about changing what is an SPF
FAIL, but what it the appropriate receiver policy in a specific case. This
will help receivers reduce their "False positives".
One of the big disadvantages of this type of approach is that it requires
waiting until after DATA to reject SPF FAIL messages. One needn't read the
whole buffer if the message is to be rejected, but you do have to wait until
it's done, so you'd lose the bandwidth savings associated with SPF rejections
now. For CPU and other resources, I don't think it would have a major
impact.
Maybe "smart" implementations could combine 1a, 1b, and 2 (?)
Sure, but that's an implementation detail, no business of the specification.
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 ?
For one, if Mail From domain != From domain, you look for both an SPF record
for the Mail From domain and the From domain [modulo macros, I haven't
thought about that yet... work to be done]. If the From domain SPF record
has op=from in it, then the message can be rejected without even calling
check_host or obtaining an SPF result.
This would provide an immediate tool to reject a class of phishes that has,
from my POV, become more common as SPF has gained popularity. That is when a
random Mail From is used to avoid SPF and then the From address is the
address the phisher wants the user to believe the message is from.
Much like the first party only DKIM SSP, this would break mailing lists and
some web enabled mailers, but to major phishing targets like, say Paypal or
Ebay, I don't think they'd care.
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:
I was thinking the strong one (I think).
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 ?
DKIM missing and invalid must be treated the same in all cases, and so those
can be combined.
I'd draw more as a sequence for now (not sure I know yet how to fill in all
the boxes):
This is for op=from=dkim in the From domain.
1. Are Mail From domain and From domain the same? If not, reject (no SPF or
DKIM processing required)
2. Check SPF, if PASS, consider the message not forged/within policy,
whatever term you like and don't bother with DKIM processing.
2.a. If SPF FAIL, then check DKIM. If no signature is present or is invalid,
reject the message. If the signature is good, then consider the message not
forged/within policy.
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).
Yes. I'd say op=nomailfrom, but yes.
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".
I disagree. It either changes what the receiver should do about the SPF
result or either eliminates the need to check for the SPF result, but PASS is
still PASS and FAIL is still FAIL. Currently deployed programs can continue
on just fine. Currently deployed records can continue on just fine.
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.
I think the op=nomailfrom would be an optimization at best. It's the least
important of these suggestions.
My bottom line point is that this is the type of stuff I think we need to be
focused on now in terms of new development efforts.
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