ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error

2006-04-21 21:13:28

----- Original Message -----
From: "Dave Crocker" <dhc(_at_)dcrocker(_dot_)net>
To: "Jim Fenton" <fenton(_at_)cisco(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, April 21, 2006 8:51 PM
Subject: Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error


Exactly right.  This is a specification concerning the message
object, not concerning message transport, even though it pertains
to the object "while in transit."

Then there is going to be alot of editing in both the base and Threat
documents because it all and intent and purposed modeled around a SMTP
system.   Then you need to invent define BCP for all other transport
concepts as well.

How will you word step 2, section 6.2?  Simply remove the parenthetical SMTP
related statement?

   2.  If the query for the public key fails to respond, the verifier
       SHOULD defer acceptance of this email.

Ok, SMTP people can see what that means. But you should have insight for
threats too.

   2.  If the query for the public key fails to respond, the verifier
       SHOULD defer acceptance of this email.  Verifiers SHOULD track
       any abuse of non-stop errors.

Or would you like to add Jim's GreyList Concept?


   2.  If the query for the public key fails to respond, the verifier
       SHOULD defer acceptance of this email.  Verifiers SHOULD track
       continuous errors and SHOULD eventually accept the message
       object after a number of tries.

Anything about DKIM that involves SMTP is probably going to need an ESTMP
option.  I suspect that that is out of scope.

SMTP or ESMTP is out of scope?

Lets see what else you need to remove now:

Section 5.1:  Remove SMTP AUTH reference.

Section 6.2:  Removal of SMTP 451 advice

Section 6.5:  Removal of asynchronous SMTP session discussion.
              Removal of response codes.  This section would
              need a massive editing.

Section 8.2:  Removal SMTP Authentication.

Appendix A.3:  Removal of critical statement of inbound SMTP
               server as a verifier.  Maybe SMTP examples
               or show other method examples or remove all
               examples.

Appendix B.1: Removal discussion about how Received: headers
              are added.

And so on and so on.  The entire document reeks SMTP and ESMTP.  This system
is modeled on a SMTP/ESMTP system so who are we kidding?  9.9 out of 10
systems, if not all, will begin using DKIM within a mail framework that
includes SMTP, including GoodMail.

If we want to generalized it, that's fine, but you need to atleast provide
insight and guidance and make sure there is no obvious "got chas" making it
too late to correct in the future not even a BCP will correct.  If it was
that easy, to use incremental BCP documents to correct the design issues
that you knew existed, we wouldn't have these problems today.  20 years ago
I can understand.  Not today, we have hundreds of thousands of man-years
here and we know enough to know what the issues are.  Ignoring them today is
engineering neglect.

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





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