ietf-dkim
[Top] [All Lists]

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

2006-03-18 10:35:19
Thanks for going back on-list. <g>

----- Original Message -----
From: "Hector Santos" <hsantos(_at_)santronics(_dot_)com>
To: <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
Sent: Friday, March 17, 2006 3:55 PM
Subject: Re: [ietf-dkim] New Issue: Analyzing Failures: List of Possible
Reasons

Why go off list Bill? :-)

In my view, you are a "necessary folk" too so post your thoughts
publicly. If you think it is FAQ material, then put it to a test
with others to see if they agree.

I personally think DKIM needs "reasons" for failures.  The
software is already doing it, it is just not put into "response
context."

I was expecting someone to say that this might be best for a
"Authorization-Result:" header where success and/or failure can
be communicated to the next party handling or viewing the mail.

But the way things are going, if you look at some of the
presentations and plans of vendors, there are expecting to "tag
and highlight" the good/valid messages with "Good DKIM seals."
There will no "bad markings" for others.

However, in my view, this is what's going to happen.

COX.COM (pick company) begins to offer DKIM "Trust Me Security"
mail systems to thier users.  They see a LIST of messages in their
inbox:

       From: so so    Date:
     $ From: so so    Date:
       From: so so    Date:
     $ From: so so    Date:
       From: so so    Date:
       From: so so    Date:
       From: so so    Date:
       From: so so    Date:
       From: so so    Date:
     $ From: so so    Date:
       From: so so    Date:
       From: so so    Date:

They see $ or whatever "Good DKIM Seal" icons for a few, but the majority
they don't.

But one of the non-$ messages is really a DKIM message but it had failed.

There will be many questions depending on a variety and combinations of
things:

1) One message was from a BANK account, DKIM signed, but it failed.
   Is it really good or bad?

2) Will the BANK contact COX.COM to find out why?

3) Will the USER contact the BANK to find out why?

4) What if it was really bad and the user lost his identity?

   Who is liable?

   COX.COM or the BANK.COM

   User sues BANK.COM.  BANK sues COX.COM.

etc, etc.  These are not non-issues, you can throw away.  These
are legal and managerial issues that inevitably will only be
solved by digging up the reasons why there was failure in the
first place.   So either you know upfront or find out later. It
will be required at some point.  Hopefully when its not too late.

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


----- Original Message -----
From: <Bill(_dot_)Oxley(_at_)cox(_dot_)com>
To: <hsantos(_at_)santronics(_dot_)com>
Sent: Friday, March 17, 2006 3:39 PM
Subject: RE: [ietf-dkim] New Issue: Analyzing Failures: List of Possible
Reasons


Your support idea is sound although I disagree on what DKIM is actually
going to do. However those issues should not be a part of a policy
document but rather an appendix or FAQ

Something along the lines of

Unsigned Message is received from publisher who claims to sign all
Treat as unsigned message

Signed message is received but decodes invalidly
Treat as unsigned message

Published dkim record indicates a 1025 hash but signature is 512
Treat as unsigned message

Hmm, I'm starting to see a pattern here :-)

Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
bill(_dot_)oxley(_at_)cox(_dot_)com



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