ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] linkage between "originator" and "handling agent"

2005-08-16 11:09:05
----- Original Message -----
From: "Arvel Hathcock" <arvel(_at_)altn(_dot_)com>
To: <ietf-dkim(_at_)mipassoc(_dot_)org>
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