ietf-mailsig
[Top] [All Lists]

RE: DKIM Verification Algorithm

2005-08-04 08:19:51

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.
==============================================================================


<Prev in Thread] Current Thread [Next in Thread>