On Dec 8, 2006, at 9:55 AM, Hector Santos wrote:
Douglas Otis wrote:
Signing is not limited to the MTA, it can be done at the MUA. In
addition, protections afforded by DKIM requires the MUA to verify
signatures or obtain trustworthy signaling from the MDA.
I'm sorry. What section in the DKIM specification does it say it
"requires the MUA to verify signatures"?
The DKIM specification does not indicate how protective benefits are
derived. It surely does not say the MUA can not verify signatures.
DKIM use at the MUA has an advantage over SPF that must often depend
upon Received headers including the optional IP address of the SMTP
client.
Blocking at the MTA can not offer adequate protection.
Why not?
You can not safely tell customers they are protected at the MTA from
spoofs with enforcement of DKIM's policies. Currently MUAs do not
adequately display email-addresses to safely allow visual
verification. When your customer assume they are protected with
assurances of MTA policy blocking, they more easily fall victim to
visual obfuscation techniques. These techniques are not handled by
DKIM when limited to just email-address domains. Protection must
also work when email-addresses are not using ASCII as well.
It would be wrong to expect blocking at the MTA via restrictive
policy produces a significant effect on the level of abuse.
Bad Guy uses my domain.com at site XYZ. Site XYZ looks up my policy
and finds he wasn't suppose to use my DOMAIN.
Whats wrong with expecting this is not a highly probably event?
Because bad actors adapt where then you might then detect a few
percent of lazy ones as with SPF. All you have done is add more
overhead, where now removing it places your customers at greater risk
after hearing your initial promise of applying DKIM policy to block.
When bad actors adapt, can you stop making searches up label trees
for each message you receive? You have created two bad problems
based upon this assumption:
1) Increased overhead for the MTA for little benefit.
2) Increased susceptibility to spoofing due to the false claim of
protection.
Blocking via policy definitely does _not_ offer much in the way of
protection, but will require a significant level of support
explaining why various messages are being rejected.
It will?
- A domain does not expect mail. Pretty good protection
- A domain requires mail to be sign. Pretty good protection
Only when message originators are recognized and verified by the MUA,
or by the MUA in conjunction with the MDA where annotation protection
can be achieved. Visual examination of a From header does not offer
"Pretty good protection". DKIM signatures themselves are invisible
by design and there should be no assumption about the method of
header display.
Those two along will cut down a very significant amount of the most
common exploitations without requiring any feedback whatsoever.
There is plenty of evidence that differs with this assessment.
Sorry, but DKIM does not enable safe visual examination of headers,
nor does it offer a viable means for reducing abuse. In fact,
without some method to associate the SMTP client with the signing-
domain, DKIM does not even offer safe white-listing in many cases.
Associative techniques can establish safer annotation for a more
secure protective scheme that does not depend upon visual examination
or a high MTA overhead. In fact, the MTA can stop checking DKIM when
the domain is not white-listed. Associative techniques eliminate any
need to share private keys, while ensuring DKIM feedback is directed
to the transmitting entity. Associative techniques protect use of
DKIM for white-listing. Associative techniques can be for specific
headers for differentiating various services. Associative techniques
can also protect the return-path. An association can be established
within a single and small DNS transaction.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
