Subject: [ietf-dkim] Itemized Summary of SSP Requirements-00

From: "Hector Santos" <[email-masked]>
Date: Tue, 29 Aug 2006 11:40:21 -0400

This might help folks who don't have the time to read the draft details and
also serve a quick summary difference when requirements-01 is completed.
Maybe it can also correct any misunderstanding, including my own.

5.1.  Discovery Requirements

5.1.1  [_] MUST use DNS RR TXT for Policy record.
5.1.2  [_] MUST converge in a deterministic number of exchanges.
5.1.3  [_] MUST fit in 512 octets

5.2.  Transport requirements

5.2.1  [_] Widespread deployment of the transport layer
5.2.2  [_] A low-cost query/response
5.2.3  [_] Caching and TTL
5.2.4  [_] Server Redundancy

5.3.  Practice and Expectation Requirements

5.3.1  [_] MUST use 2822.From domain only.
5.3.2  [_] MUST allow "No Mail Policy"
5.3.3  [_] MUST allow "DKIM Signing Complete"
5.3.4  [_] MUST allow "1st party signature expected"
5.3.5  [_] MUST allow "Known 3rd party signature"
5.3.6  [_] MUST NOT mandate receiver handling of mail.
5.3.7  [_] MUST allow "Null Practice" ("May Sign Mail?")
5.3.8  [_] NOT Required to have a "Blacklist of signing domains"
5.3.9  [_] NOT required for valid 1st party signatures
5.3.10 [_] MUST allow for list of acceptable hashing methods

5.4.  Extensibility and Forward Compatibility Requirements

5.4.1 [_] MUST NOT be used for other technology.
5.4.2 [_] MUST ALLOW for new policies
5.4.3 [_] MUST ALLOW for new protocols signed by DKIM
5.4.4 [_] MUST ALLOW for protocols other than DKIM

6.  Security Requirements

6.1 [_] Minimize DoS potential
6.2 [_] Amplification Attacks
6.3 [_] Authenticity

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

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 Aug 2006 15:45:32 -0700

Just as a note, this is not a summary of the current draft, and it 
includes things
that I've seen no support for to date. I'd appreciate it if we stick 
with what I
actually wrote down, suggest language changes and/or new requirements 
instead
of reinventing a whole new draft. As experience has shown,  all this 
will do is
bifurcate understanding as this list is an extremely poor wiki.

       Mike