* 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.
If the query for the public key fails to respond, the verifier SHOULD defer acceptance of this email. Verifiers MAY track continuous errors and determine the message has a broken signature. thanks, Bill -----Original Message----- From: [EMAIL PROTECTED] on behalf of Hector Santos Sent: Sat 4/22/2006 12:03 AM To: [EMAIL PROTECTED]; Jim Fenton Cc: [email protected] Subject: Re: [ietf-dkim] dkim-base-01: 6.2 - DNS error ----- Original Message ----- From: "Dave Crocker" <[EMAIL PROTECTED]> To: "Jim Fenton" <[EMAIL PROTECTED]> Cc: <[email protected]> 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 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
