Scott Kitterman wrote:
SPF + DKIM by itself can never reject before DATA.
That's a new idea. My naive concept of SPF + DKIM was:
- reject on FAIL (otherwise it's no SPF as specified)
- optionally (your proposal) byPASS DKIM for PASS
- normal DKIM for the rest (at least for NEUTRAL)
SPF + op=DKIM + DKIM can still reject before data
for SPF Fail without op=DKIM.
Hard to parse... ;-) Please correct me if I got it
wrong:
A system supporting SPF + DKIM + op=dkim sees a FAIL
for a sender poliy _without_ op=dkim. It will then
reject as specified.
OTOH if the same system sees a FAIL for a policy
_with_ op=dkim it will ignore the FAIL (not reject).
In other words your idea of op=dkim would be "ignore
SPF FAIL if you have DKIM". That would be the first
case of an "opt-out" op, here opt-out of SPF FAIL :-)
This isn't about SPF per se, but how one might
combine two technologies to get a better result.
Yes, with tons of conditions before you arrive at
cases where it actually has a effect.
For the technical side, we have only the 4 known
results (+ 2 error results). For your idea the
receiver would configure "I support DKIM" in his
op=dkim-aware checkhost().
Then checkhost() could return NEUTRAL instead of
FAIL or SOFTFAIL for a sender policy with op=dkim.
With that trick the SPF FAIL was disabled as you
wanted it, and DKIM can process the DATA later.
Some difficulties: It's a "virtual NEUTRAL", not
a real NEUTRAL, therefore it must not show up in
any Received-SPF header field.
Second problem, what if the DATA later has no
DKIM header fields ? Does your idea work only
in conjunction with an "always signed" SSP ?
Or does the "virtual NEUTRAL" for op=dkim also
modify the later DKIM behaviour, something in
the direction of "delayed reject with SPF FAIL
if DKIM doesn't PASS" ?
The latter is more interesting, what you are
creating here is a new implementation layer on
top of both SPF and DKIM, because you need the
old "virtual NEUTRAL" (after DKIM didn't PASS)
for the "delayed reject".
A better name for "virtual NEUTRAL" could be
"conditional FAIL" (the condition is that it's
not overruled by a DKIM PASS).
Or "deferred FAIL". The problem is that SPF
as shipped can't report it directly. Screw
my bad idea "virtual NEUTRAL", what you really
need is the normal result like FAIL plus some
flag to report "but has op=dkim".
And an engine / layer / whatever that delays
the normal FAIL reject until DKIM got a chance.
The whole effort is another solution for the
"forward-thing", for cases where both sides
(sender+receiver) support both SPF and DKIM.
OTOH it hurts receivers which are not at all
affected by the "forward thing", they have
to go through DATA and DKIM before they can
finally reject the forged mail.
My gut feeling: That's too complex at the
moment. Or rather it needs more discussion:
E.g. is this a scheme that could also work
for "op" in the old "other protocol" sense ?
So far we have:
- needs a way to report result + condition
- needs a layer to act on the result later
if the condition isn't met (and v.v.)
- could we (ab)use Received-SPF for some
kind of inter-process-communication (SPF
to the DATA processing) ?
Bye, Frank
-------
Sender Policy Framework: http://spf.pobox.com/
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