[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