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

From: <[email-masked]>
Date: Fri, 17 Mar 2006 14:36:19 -0500

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-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] 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

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 17 Mar 2006 15:09:32 -0500

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, March 17, 2006 2:36 PM
Subject: RE: [ietf-dkim] New Issue: Analyzing Failures: List of Possible
Reasons

> 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.

Right, and we will get the quesitions, "why?"

> As an ISP I don't want anypart of the liability that comes
> into "this message is good" "that message is bad"

Well, unfortunately, if you add DKIM, you will be assuming liability whether
you agree with it or not.  It is a new level of responsibility, especially
for those who begin to put a cost associated with it.

Anyway, even if your TSO proclaims no liability, what are you going to do
with the support questions?  I was more concern with the obvous support
questions behind this.  Are we ready to proclaim DKIM is a "Plug and play -
No Support Required" protocol?   I don't think so.

> 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.

Right, but there will still be support questions and the odds are good that
your local policies will be molded based on the support issues.

> DKIM has never been a authentication service, just
> an identification service.

I don't agree with those semantics.  IMO, the fact is, you are
authenticating the identity of a domain by implementing DKIM processing.
That's is exactly what you are doing:

      Domain Identity Authentication via DNS DKIM records

Maybe you are saying it is not an authorization concept. If so, I agree
although there are dispensed semantics in the docs that suggest that a valid
identification promote authorization for acceptance.

In any case, the very fact there is there is no absolute, in the
technicality and/or the politics of DKIM,  there will be many support issues
for this very reason.  When you have people who are going to suffer the
consequences of increase abused DKIM messages, there is no doubt in my mind
there will be a higher scrutiny placed on the bad as well as the good.

All I am suggesting is to help the process by giving verifiers the "means"
to better identify the failures in a standard fashion so that there will
less support questions.

PS: To the "necessary folks", ignoring these concerns is in my view
negligent of the engineering process. Don't be surprise of the "future
critics" when the issues were pointed out now and you opted to ignore the
messenger now in attempt to promote negative consensus and avoid
highlighting the issue.  So if you are concern about the future critics, you
best to begin molding the answers now to the these concerns.