I don't think presenting dkim information pro-actively to the end user serves any useful purpose. Unlike PGP the user doesn't have an easy way to decode what the header is telling them. In a few specific cases I will reject mail based on a lack of dkim signatures. We do not envision using dkim to bypass anti-spam, anti-virus or anti phishing services we provide. It will be very useful when a properly decoded dkim sig contains objectionable material, we now know who we can complain to instead of guessing. The only support calls I envision are the same ones we get now, from organizations that wonder why their messages are getting bounced. DKIM may add to that but not significantly, Thanks,
Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: Hector Santos [mailto:[EMAIL PROTECTED] Sent: Saturday, March 18, 2006 12:42 PM To: Oxley, Bill (CCI-Atlanta) Subject: Re: [ietf-dkim] New Issue: Analyzing Failures: List of Possible Reasons Offlist: Does it means you plan to use DKIM deterministically? Reject at the SMTP level? _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
