ietf-dkim
[Top] [All Lists]

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

2006-03-17 13:17:39

----- Original Message -----
From: <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
To: <hsantos(_at_)santronics(_dot_)com>; <ietf-dkim(_at_)mipassoc(_dot_)org>
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.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com









_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html