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
bill(_dot_)oxley(_at_)cox(_dot_)com
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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