----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
Jim Fenton wrote:
I'll throw out a few generic requirements:
Jim, these all look pretty reasonable, but they are all about
the mechanism rather than being about sender signing practices,
per se.
+1
It is probably a good idea if we can break down the requirements into three
categories; system vs. security vs. application requirements.
Here's my short list breakdown. Includes those already discussed. Of
course, depending on the style of your hat, some of these may fall into
different and/or multiple categories. I am just listing them, not locked
into any one, with the goal to help speed things up (I should also note that
I do not believe these in any way fall into a "featurlitis" syndrome, but I
do hope we are good enough to see what's required and then go from there).
o System Requirements:
- DNS based
- DNS TXT RR
- Low-cost query/response
- Minimal Lookup
- Easily cached (Implied by DNS requirement?)
- High availability (Implied by DNS requirement?)
- System Integration flexibility (can work outside of 821)
- Support MLS (Mailing List Servers)??
- Support for MFA (Mail Filter Agents) such as SA, SIEVE, etc.
o Security Requirements:
- Protection of OA domain signature is paramount.
- Protect against unauthorized policies.
- Minimize DoS potential
- Consideration for high Failure/Success ratio.
o Application Requirements:
- Allows for high efficiency implementation
- Ease of definition
- Flexible syntax for growth
- Definition should expose the following DKIM signer attributes:
- Support OA Mail/DKIM Policy definitions
- No mail expected from OA
- Never Signed expected from OA
- Always signed expected from OA
- Sometime signed expected from OA
- Support 3PS Mail/DKIM Policy definitions
- Not expected by OA
- Always expected by OA
- Sometimes expected by OA
- Highest Signature Hashing method Possible
- List of allowable 3PS signers
- Reporting address
- Failure handling
- DKIM Verifiers with SSP implementators do not need to
support DKIM signing. (This helps with migration)
- Does not required CAR (Certification, Accreditation, Reputation)
service layer.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html