ietf-dkim
[Top] [All Lists]

[ietf-dkim] New Issue: Analyzing Failures: List of Possible Reasons

2006-03-17 12:30:11
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

<Prev in Thread] Current Thread [Next in Thread>
  • [ietf-dkim] New Issue: Analyzing Failures: List of Possible Reasons, Hector Santos <=