I don't think that user recipients are going to see dkim anything unless they are used to viewing their headers. A dkim failure is just an identification failure, not a stop delivery notice. All it means is that I cant clearly identify who sent me this. As an ISP I don't want any part of the liability that comes into "this message is good" "that message is bad" If I use a visible identifier software the message will say "software vendor BLA has declared this message safe". Any dkim failure or breakpoint is an unsigned message that the local retailer will process for the end user as local policy permits. DKIM has never been a authentication service, just an identification service.
Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hector Santos Sent: Friday, March 17, 2006 2:27 PM To: IETF-DKIM Subject: [ietf-dkim] New Issue: Analyzing Failures: List of Possible Reasons Proposal: I think section 6.5 is a good step but we need a section that is dedicated to all the possible reasons for failures as we KNOW it to possibly to occur. I think there should a special section: 6.6 List of Possible Failures This section would include a discussion on failures and prepare a list of possible reasons, including probably summarize the set of standard error response codes and/or labels for verifiers and or mail presentation software to use. - Missing Public Key - Missing Header Information - Hashing Failure Which part? Header or Body? - Signature has Expired - Subject Mismatch - Policy Conflict (SSP related) etc. Background: One of the concerns I see that is going to occur is a huge expense in support in answering customers questions as to why this or that message failed or has a warning tag or lacks having a "GOOD DKIM SEAL" tag when it should have one, etc, which ever way the verifier and/or reader wishes to present this stuff. As we consider adding DKIM signing, I can see the issues when the target final destinations verifiers and/or readers start to see non-GOOD messages. There is going to be a lot of questions coming our way to explain why. We need to be prepare to answer them. First I expect the support questions: "We turned this on and now YAHOO/AOL is saying our messages are bad. Is it me or your software?" "We began to charge a few our customers for domain signing, and they are saying there customers are getting bad messages.. What's going on?" and then worst - finger pointing and passing the support buck: "According to XYZ, you are not signing right..." "Maybe your software is changing text...." and I am sure more questions in this vain, and then I expect even more "passing of the buck" finger pointing excuses: "Well, somewhere the message was broken in the route." "Maybe it is really bad?" "Maybe the verifier is broken?" In any case, what is really missing from DKIM is the "reasons" for failure that verifiers can use to help alleviate these support issues. I predict there is going to be a lot of chaos in this area, especially when the "two-tier" divide begins due to the bigger concentrating in sniffing out the good out the big haystack of the bad or even bigger haystack of non-DKIM messages. What bothers me greatly is that I foresee the era when the BAD, by a far majority, outweighs the GOOD to the extent that it has a "Cry Wolf" effect and people simply just start ignoring all the bad markings or "lack of good markings" messages. In some respect, I can see why some would want to "hide" failures, so that there would be less "explanations" for the failures. But IMO, if there is going to be an increase of "bad messages" with DKIM markings, I think it would be better to help verifiers support operations to increase the confidence of the system. By promoting the idea that these bad messages should be viewed as "No Signatures" messages, I can't help but seeing a "cry wolf" syndrome to occur. We already see this now with mangled listed mail. We accept them - even with broken DKIM/DKEY signatures. -- Hector Santos, Santronics Software, Inc. http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html