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
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: Hector Santos [mailto:hsantos(_at_)santronics(_dot_)com]
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