Jim,
I am a little confused than of the distinction between testing DKIM and
testing Signing Policy. Can someone have a key record that is not being
tested, but an SSP record that is being tested? Does this make sense,
and what affect will this have on the matrix below?
Graham
-----Original Message-----
From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
Sent: Thursday, August 04, 2005 4:20 PM
To: Graham Finlayson
Cc: IETF-MAILSIG
Subject: Re: DKIM Verification Algorithm
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.
==============================================================
================
"Tumbleweed E-mail Firewall <tumbleweed.com>" made the following
annotations on 08/04/05 08:46:26
------------------------------------------------------------------------------
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.
==============================================================================