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
