On 1/13/11 9:10 AM, Dave CROCKER wrote:
Folks,
Summary of the reactions posted so far...[1]
Some of the postings asked questions or expressed confusion about some
procedural or technical or wg scope "fact" issues that have already been
answered; so they are not covered here. Also, there might be some relatively
minor points that I've skipped, for simplicity in this summary. That doesn't
mean they should be ignored, merely that my own reading classes them as
outside
of the critical path for the current question of whether to do a documentation
split.
For background, here's a baseline summary of the vector the working group is
/already/ on:
1. DKIM will have a new RFC number.
2. DKIM currently covers more than one RFC:
The original one and the update.
3. Documentation changes are already being made.
Dave,
Sorry for being slow to comment. Benefits obtained from reuse of DKIM
components would be through the leveraging of existing code. However,
very soon DANE will offer code having better security in generalized
form. Consensus about verification results reflecting whether the
underlying format is invalid and able to produce misleading results
becomes less likely for DKIM, in conjunction with efforts to further
generalize verifications.
While DKIM is a good mechanism at preventing false positive detections
of phishing attempts, an inability to hold a source accountable for
specific destinations makes it unsuitable for playing a meaningful role
in establishing spam specific reputations. This too suggests DANE will
likely play a greater role over time.
Promoting the third-party authorization scheme was an effort to improve
DKIM's deliver-ability and did so by then depending upon client
authentication methods absent from DKIM. As use of v6 becomes a greater
consideration, IP addresses will not offer an identifier suitable for
policy enforcement, where again DANE is more likely able to fill that
gap. DANE has not yet closed the door, but it will very soon.
When used as a basis for acceptance, DKIM comes too late in the
exchange, where again DANE will also likely play a greater role.
Perhaps when email acceptance is based upon authenticated domain
sources, the need to "introduce" third-party domains will become more
apparent. Nevertheless, TPA, and something like DANE, whether it
leverages DKIM or not, is where email needs to head.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html