On Mon, 12 Sep 2005 07:36:19 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
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 :-)
Yes. Not really opt-out of fail, but a conditional willingness to go to
DATA.
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.
Yes. Op=DKIM would be useful only where you need it. Flip side not yet
discussed is is DKIM worth the trouble if you already have SPF Pass.
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" ?
That's along the lines of what I was thinking. I'm thinking no 3rd party
signatures for this purpose.
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".
Yes. SPF was originally Sender Permitted From. I think that is designed
and now the trick is to develop an actual Sender Policy Framework (aka
Unified). Since SPF happens before the DATA phase methods it's the logical
place to give hints about what's to come.
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.
Yes. Key point is forwarders needn't change.
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.
Only if they want to. It's a modifier and receivers, by definition are
free to ignore it.
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 ?
Definitely needs more discussion - agreed.
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) ?
I think it's an implementation detail, but we should think about it.
Scott K
-------
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