----- Original Message -----
From: "Arvel Hathcock" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Tuesday, August 16, 2005 12:48 PM
Subject: Re: [ietf-dkim] linkage between "originator" and "handling agent"


>
> Before responding, I want to clear up something that's been bugging me a
> little lately.  I've seen the unfortunate habit of speaking about
something
> called "SSP" as if it were foreign to or a mere enhancement of DKIM.  In
my
> view, SSP is DKIM.  It is the heart and soul of the proposal.
>
> .....

I agree.

IMTO, without SSP Consistency Checking, DKIM is essentially worthless (hard
to justify usage).

I would like to revisit the table I produced at:

Legend:

SSP Policies:

         NONE (no policy [1])
    o=?  WEAK (signature optional, no third party, see [2])
    o=~  NEUTRAL (signature optional, 3rd party allowed)
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

[1} a NONE policy is possible where there is no declaration for a SSP.

[2] Arvel suggested another policy called WEAK which satisfies a
signature optional but not allowing 3rd party signers.

Verify Results:

NONE     - No signature in mail
PASS     - Good Signature, Original Address Signer
PASS 3P3 - Good Signature, 3rd party Signer

FAIL     - Bad Signature, Original Address Signer
PASS 3P3 - Bad Signature, 3rd party Signer


Table 1.0 - DKIM Verification States illustrates all possible
            outcomes for signature verification 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  |
+------------------------------------------------------------------+

A few of these are subjective, but most are hard decisions based on the
SSP consistency checking.

Why is this important?

- Help strengthen the protocol (make it worthwhile)

- Provide optimization logic when fitting DKIM into
  a mail vendor framework. i.e., minimizing payload requirements.
  This is an implementation consideration.


--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com





_______________________________________________
ietf-dkim mailing list
http://dkim.org

Reply via email to