Graham,
The key record also has a t= flag. Will that do?
-Jim
Graham Finlayson wrote:
Jim,
I also would like to not have to do this additional SSP DNS lookup where
possible. Unfortunately, I think your optimization will not work due to
the t= flag that can be present in the SSP.
This could be overcome if the testing information could be moved into
the DKIM-Signature header field.
Graham
-----Original Message-----
From: owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-mailsig(_at_)mail(_dot_)imc(_dot_)org] On Behalf Of Jim Fenton
Sent: Thursday, August 04, 2005 9:06 AM
To: william(at)elan.net
Cc: Hector Santos; IETF-MAILSIG
Subject: Re: DKIM Verification Algorithm
I think I missed the beginning of this thread somehow. I
think this matrix came from Hector; I rather like it because
it frames the discussion well:
I will draw the outcome table in text mode. View it in
fixed pitch mode.
Table 1.0 - DKIM Verification States illustrates all possible
outcomes for signature verifcation against SSP.
+------------------------------------------------------+
| Sender Signing Policy Result |
+-----------+----------------------------------------------+-------|
| result | WEAK | NEUTRAL | STRONG | EXCLU | NEVER
| NONE |
| verify | OPT | OPT/3PS | REQ/3PS | REQ |
| |
+-----------+--------+---------+---------+--------+--------+-------|
| NONE | accept | accept | reject | reject | reject
| accept|
|-----------+--------+---------+---------+--------+--------+-------|
| PASS | accept | accept | accept | accept | reject
| warn |
|-----------+--------+---------+---------+--------+--------+-------|
| PASS 3PS | reject | warn | accept | reject | reject
| warn |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL | warn | warn | warn <.-+> warn | reject
| warn |
|-----------+--------+---------+-------+-+--------+--------+-------|
| FAIL 3PS | reject | warn | warn <|-+> reject| reject
| warn |
+--------------------------------------+---------------------------+
Maybe I'm focusing on an optimization here, but I'm still
trying to see if we can avoid checking SSP when there is a
valid originator signature present. The primary case here
that requires it is NEVER. In that case, the originating
domain must have published some key records, but is asserting
that it doesn't send any mail. This seems like a conflict,
which could be resolved in either direction. I tend to think
that having a valid signature is a stronger assertion than
the SSP, so why not fold NEVER into EXCLUSIVE?
Also, I think that a valid OA signature shouldn't result in a
warning if there is no SSP published, which makes NONE the
same as NEUTRAL, again for the reason that the signature is a
stronger statement than the policy. It also makes
publication of policy optional.
-Jim
"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
annotations on 08/04/05 08:17:15
------------------------------------------------------------------------------
This e-mail, including attachments, may include confidential and/or proprietary
information, and may be used only by the person or entity to which it is
addressed. If the reader of this e-mail is not the intended recipient or his
or her authorized agent, the reader is hereby notified that any dissemination,
distribution or copying of this e-mail is prohibited. If you have received this
e-mail in error, please notify the sender by replying to this message and
delete this e-mail immediately.
==============================================================================