----- Original Message ----- From: "Andrew Newton" <[EMAIL PROTECTED]>
> My comments are in-line: > > On Aug 1, 2005, at 6:13 AM, Dave Crocker wrote: > > By way of seeding discussion, here is a feeble attempt (ie, my own) > > at creating > > a draft response. > > Don't sell yourself short. I don't think I could do any better, and > by the looks of it most people on this mailing list aren't even trying. Well, Andrew, atleast for me, I would really like to be part of this effort, but I can't help but feel it is a becoming a waste of time. Dave hasn't responded to any the discussions to the rather large threads regarding the DKIM signers and verifiers double checking OA SSP. Does that mean he doesn't agree with it? Does he think its "Troll material" and the less you respond the quicker it will die? He has been quoted having such a belief, so why bother? That said, the OA SSP verification issue, to me, is the most important issue in DKIM and to me, it is a near show stopper for DKIM acceptance. If it has not been said yet, this issue plays right into the key questions: - What does DKIM solve? - What are the benefits? - What are the negatives? - Where are the holes (Exploits, Bad Actors, Bad middle ware, Risk)? - Can it be done? To me, I thought DKIM was trying to protect "email domains" with an obvious benefit of addressing spoofing and phishing, especially for strong exclusive policy holders. Those with high value email and exclusive SSP policies can benefit greatly I think. Its negatives, outside the security issues (holes), are probably a change in software design at various levels in order to be effective. The holes, to me, is pretty obvious that it begins with the relaxed and 3rd party signing provisions. This is where the fuzziness is located. And I believe it can be done, but the degree of effectiveness will largely be based on both ends of the software honoring the OA SSP policies. So I think DKIM cogs really need to work out the relaxed and 3rd party signing issues because this is where the threats will largely be located. Seriously, if this part is ignored, I can't see how I can implement DKIM with any degree of confidence or trust in its results. If we learned anything from DNS based solutions such as SPF where there are relaxed provisions, it will get exploited and by my measurements, by nearly 44% of all SPF results are relaxed. A secondary CBV check on these result in nearly a 66% rejection. Consider the fact that DKIM is a payload solution, you do recall that SENDERID did have a thorn on its side over it being a PAYLOAD solution as well. The difference here, is that I think there is a degree of technical merit for DKIM payload analysis. SenderID has none. For over 80% of all transactions, the PRA is equal to the x821.MailFrom, clearly showing that it is pure overhead the majority of time. DKIM has merit because it depends on a new entities introduces into the system. Entities that increase and create new assertions on the validity of the transaction that can only exist with a new presumed higher intelligence in new software. The problematic issue of legacy software is filtered out of the analysis. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
