Hector,
Thanks; it's good to get some comment on the SSP document as well.
One thing that occurred to me (prompted by a phone call from a
colleague) is that signing policy really needs to have two dimensions:
1. What signatures are required? None, third-party, or first-party
(From: address) only?
2. How would the From: address domain like the verifier to treat
failures? Some possibilities: Reject outright, warn user, send warning
to r: address (need to be concerned with privacy issues here), etc.
Does this fit with what you have in mind?
-Jim
Hector Santos wrote:
The document draft-allman-dkim-ssp-00, section 5 defines the Outbound
signing policy tag, "o=".
| o= Outbound signing policy for the entity (plain-text; OPTIONAL,
| default is "~"). Possible values are as follows:
|
| ~ The entity signs some but not all email.
|
| - All mail from the entity is signed; unsigned email MUST NOT
| be accepted, but email signed by a third party SHOULD be
| accepted.
|
| ! All mail from the entity is signed; third-party signatures
| SHOULD NOT be accepted
|
| . This entity never sends email. The "." policy can be used
| to "short circuit" searches from subdomains; for example, the
| "ad.jp" domain might use this. If an initial policy search
| receives this policy then the email SHOULD NOT be accepted; if
| found while searching parent domains then the search should
| terminate as though no policy record was found.
|
| ^ Repeat query at user level. This value MUST NOT be used in
| user-level policy records.
I think that one of the problems with DKIM is how easy (high probability)
the signing process can be broken during transit.
What is missing is a policy on how to handle a broken verification
(non-signed or signed).
I suggest a new policy o=$ tag value to reflect the high value a domain has
on the email. A suggested wording could be:
o=$ (High Value Email)
All mail from the entity is signed; unsigned email
MUST NOT be accepted, but email signed by a
third party SHOULD be accepted. All mail that fails
verification due to some broken DKIM entity SHOULD be
reported to company (r=) [before accepting].
Issues to discuss:
- Use this tag or refined o=- to include non-signed or broken signed
verifications.
- Reporting should be a SHOULD not MUST because spammers can use this as a
feedback mechanism as well, in addition, MTAs should have the final say on
any further reporting overhead.
- Should the email be accepted or rejected (temporary or permanent) while
the reporting takes place? A company may not want this to occur for
their high valued email.
Point to consider:
In my opinion, MTA will not tolerate infinite failed DKIM transactions.
The same issue has developed with SPF with its relaxed policy provisions
(neutral, softfail). I would say that DKIM tag o=- is a neutral, and o=$
would be a softfail like concept. As a result, some SPF implementations
have already began to send reports or verify domains to obtain negative or
positive feedback on the neutral and softfail result.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com