>> [l=n might be very confusing.] > My answer is that the ISP who fails to scan a message, is an idiot > and deserves to go out of business.
A) Who sent what is not important? B) Key security? Limitations placed upon linking headers with the signing-domain also means hundreds or thousands of private keys might need to reside at the MTAs. While CNAME references could allow a common key to be used where the public key is indirectly published by perhaps thousands of customer's domains. This still obscures who signed the message, and ensures thousands are domains are at risk and may remain unaware of a detected security breach. C) Domain security? Parent signing validation can not be equated to being covered by existing domain delegation agreements. Services and keys at high-level domains create risk without any established arrangements or contracts. E) Discouraging signature verification by the end user? Rather than ensuring messages sent to the end user remains protected, this mode of protection is discouraged? A case of poor wording? F) Overlooking DDoS concerns? Not ensuring linkage between headers on who's behalf the signature is being applied weakens DDoS preventions. The base draft also expects known bad signatures to NOT be removed. G) Annotation? Annotation must take place at the MUA or signatures are invalidated. It seems MTA vendors wish to retain DKIM completely within their baliwick. Without the effort joined by MUA and web client (browser extensions) vendors, DKIM is likely to increase phishing success rates. H) EAI related changes? Ignoring developing changes because it affects visual recognition / policy blocking strategies many erroneously expect to offer end user protection. Yes, we need DKIM. This list was made on reflection of Jon's statement. The DKIM WG could have done better. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
