idnits 2.17.1 draft-kucherawy-dkim-atps-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 29, 2011) is 4474 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 292, but not defined == Missing Reference: 'THIS MEMO' is mentioned on line 473, but not defined ** Obsolete normative reference: RFC 5451 (ref. 'AUTHRES') (Obsoleted by RFC 7001) -- Obsolete informational reference (is this intentional?): RFC 5226 (ref. 'IANA') (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual submission M. Kucherawy 3 Internet-Draft Cloudmark, Inc. 4 Intended status: Experimental December 29, 2011 5 Expires: July 1, 2012 7 DKIM Authorized Third-Party Signers 8 draft-kucherawy-dkim-atps-13 10 Abstract 12 This experimental specification proposes a modification to Domain 13 Keys Identified Mail (DKIM) allowing advertisement of third-party 14 signature authorizations that are to be interpreted as equivalent to 15 a signature added by the administrative domain of the message's 16 author. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 1, 2012. 35 Copyright Notice 37 Copyright (c) 2011 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2.1. Keywords . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.2. E-Mail Architecture Terminology . . . . . . . . . . . . . 3 56 3. Roles and Scope . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Queries and Replies . . . . . . . . . . . . . . . . . . . . . 4 58 4.1. Hash Selection . . . . . . . . . . . . . . . . . . . . . . 4 59 4.2. Extension to DKIM . . . . . . . . . . . . . . . . . . . . 5 60 4.3. ATPS Query Details . . . . . . . . . . . . . . . . . . . . 5 61 4.4. ATPS Reply Details . . . . . . . . . . . . . . . . . . . . 6 62 5. Interpretation . . . . . . . . . . . . . . . . . . . . . . . . 7 63 6. Relationship to ADSP . . . . . . . . . . . . . . . . . . . . . 7 64 7. Experiment Process . . . . . . . . . . . . . . . . . . . . . . 8 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 66 8.1. ATPS Tag Registry . . . . . . . . . . . . . . . . . . . . 8 67 8.2. Email Authentication Method Name Registry Update . . . . . 9 68 8.3. Email Authentication Result Name Registry Update . . . . . 9 69 8.4. DKIM-Signature Tag Specification Registry . . . . . . . . 11 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 9.1. False Privacy . . . . . . . . . . . . . . . . . . . . . . 11 72 9.2. Transient Security Failures . . . . . . . . . . . . . . . 11 73 9.3. Load on the DNS . . . . . . . . . . . . . . . . . . . . . 12 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 76 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 77 Appendix A. Example Query and Reply . . . . . . . . . . . . . . . 13 78 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 [DKIM] defines a mechanism for transparent domain-level signing of 83 messages for the purpose of declaring that a particular 84 Administrative Mail Domain (ADMD) takes some responsibility for a 85 message. 87 DKIM, however, deliberately makes no binding between the DNS domain 88 of the signer and any other identity found in the message. Despite 89 this, there is an automatic human perception that an author domain 90 signature (one for which the RFC5322.From domain matches the DNS 91 domain of the signer) is more valuable or trustworthy than any other. 93 To enable a third party to apply DKIM signatures to messages, the 94 DKIM specification suggests delegation to a third party of either 95 subdomains or private keys, so that the third party can add DKIM 96 signatures that appear to have been added by the Author ADMD. Absent 97 is a protocol by which an Author ADMD can announce that specific DKIM 98 signatures on its mail, which are added by other ADMDs, are to be 99 treated the same as a signature by the Author ADMD itself. This memo 100 presents an experimental mechanism for doing so. 102 ATPS augments the semantics of DKIM by providing to the verifier 103 multiple identifiers rather than one. Specifically, it validates the 104 identifier found in the DKIM signature, and then provides the 105 RFC5322.From domain for evaluation. 107 2. Definitions 109 2.1. Keywords 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [KEYWORDS]. 115 2.2. E-Mail Architecture Terminology 117 Readers are advised to be familiar with the material and terminology 118 discussed in [MAIL] and [EMAIL-ARCH]. 120 3. Roles and Scope 122 The context of this protocol involves the following roles: 124 o ADministrative Mail Domain (ADMD)s, whose DNS domain name(s) 125 appear in the RFC5322.From field of a [MAIL] message; 127 o ATPS Signers, which apply [DKIM] signatures using their own 128 domains, but on behalf of the message Author's ADMD; and 130 o the Verifier, who implements the signature validation procedures 131 described in [DKIM]. 133 An ADMD implements this protocol if it wishes to announce that a 134 signature from any in a set of specified DNS domains is to be 135 considered equivalent to one from the ADMD itself. One might, for 136 example, wish to delegate signing authority for its DNS domain to an 137 approved messaging service provider without doing the work of key 138 transfer described in Appendix B.1.1 of [DKIM]. This is communicated 139 to Verifiers via a new tag in the DKIM signature. 141 A Verifier implements this protocol if it wishes to ensure that a 142 message bears one or more signatures from sources authorized to sign 143 mail on behalf of the ADMD, and identify for special treatment mail 144 that meets (or does not meet) that criterion. It will do so by 145 treating the signer's authorization on behalf of the author's ADMD to 146 mean that the signer's signature is equivalent to one affixed by the 147 author's ADMD. 149 4. Queries and Replies 151 This section describes in detail the queries issued, the replies 152 received, and how they should be interpreted and applied. 154 4.1. Hash Selection 156 The author's ADMD will indicate authorization of a third party to 157 sign its mail via the presence of a DNS TXT record that contains an 158 encoding of the third party's DNS domain name. The encoding 159 mechanism is constructed so that any domain name can be added to the 160 DNS in a fixed length, so that longer third-party domain names are 161 not excluded from participation because of the overall length limit 162 on a DNS query. 164 Part of the mechanism requires constructing a digest of the third 165 party's DNS domain name. The author ADMD MUST select a digest 166 ("hash") method currently supported by DKIM (see Section 7.7 of 167 [DKIM]), and this selection needs to be communicated to the ATPS 168 Signer as it is used in generation of its the third party signatures. 170 The full DNS mechanism is specified in Section 4.3. 172 4.2. Extension to DKIM 174 [DKIM] signatures contain a "tag=value" sequence. This protocol will 175 add additional tags called "atps" and "atpsh". 177 When the ATPS Signer generates a DKIM signature for another ADMD, it 178 MUST put its own domain in the signature's "d" tag, and include an 179 "atps" tag that has as its value the domain name of the ADMD on whose 180 behalf it is signing. 182 The tag name that carries the name of the selected hash algorithm is 183 "atpsh". If absent, the Verifier MUST assume "sha1". 185 The formal syntax definition, per [ABNF]: 187 dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name 189 dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP key-h-tag-alg 191 "domain-name" and "key-h-tag-alg" are defined in [DKIM]. 193 The registration for these tags can be found in Section 8. 195 4.3. ATPS Query Details 197 When a [DKIM] signature including an "atps" tag is successfully 198 verified, and is considered acceptable to the Verifier according to 199 any local policy requirements (which are not discussed here or in 200 [DKIM]), the Verifier compares the domain name in the value of that 201 tag with the one found in the RFC5322.From field of the message. The 202 match MUST be done in a case-insensitive manner. 204 If they do not match, the "atps" tag MUST be ignored. 206 If they do match, the Verifier issues a DNS TXT query, as specified 207 below, looking for confirmation by the Author ADMD that the ATPS 208 Signer is authorized by that ADMD to sign mail on its behalf. Where 209 multiple DKIM signatures are present including valid "atps" tags, 210 these queries MAY be done in any order or MAY be done in parallel. 212 Where the RFC5322.From field contains multiple addresses, this 213 process SHOULD be applied if the "atps" tag's value matches any of 214 the domains found in that field. These MAY be done in any order. 216 Note that the algorithm uses hashing, but this is not a security 217 mechanism. See Section 9.1 for discussion. 219 The name for the query is constructed as follows: 221 1. Select the hash algorithm from the "atpsh" tag in the signature. 222 If none, the default is "sha1". If one is specified but does not 223 appear in the list registered with IANA as one valid for use with 224 DKIM (see Section 7.7 of [DKIM]), abort the query. 226 2. Extract the value of the "d=" tag from the signature. 228 3. Convert any upper-case characters in that string to their lower- 229 case equivalents. 231 4. Feed the resulting string to the selected hash algorithm. 233 5. Convert the output of the hash to a string of printable ASCII 234 characters by applying base32 encoding as defined in Section 6 of 235 [BASE32]. The base32 encoding is used because its output is 236 restricted to characters that are legal for use in labels in the 237 DNS, and evaluates the same way in the DNS whether encoded using 238 uppercase or lowercase characters. 240 6. Append the string "._atps." 242 7. Append the domain name found in the "atps" tag of the validated 243 signature. 245 The query's formal syntax definition, per [ABNF]: 247 atps-query = 1*BASE32 %x2e.5f.61.74.70.73.2e domain-name 249 BASE32 = ( ALPHA / %x32-37 ) 251 See Appendix A for an example of a query construction. 253 4.4. ATPS Reply Details 255 In the descriptions below, the label NOERROR symbolizes DNS response 256 code ("rcode") 0, and NXDOMAIN represents rcode 3. See Section 4.1.1 257 of [DNS] for further details. 259 At this time, only three possibilities need to be identified in this 260 specification: 262 o An answer is returned (i.e. [DNS] reply code NOERROR with at 263 least one answer) containing a valid ATPS reply. In this case, 264 the protocol has been satisfied and the Verifier can conclude that 265 the signing domain is authorized by the ADMD to sign its mail. 266 Further queries SHOULD NOT be initiated. 268 o No answer is returned (i.e. [DNS] reply code NXDOMAIN, or NOERROR 269 with no answers), or one or more answers have been returned as 270 described above but none contain a valid ATPS reply. In this 271 case, the Signer has not been authorized to act as a third-party 272 signer for this ADMD, and thus the Verifier MUST continue to the 273 next query. 275 o An error is returned (i.e. any other [DNS] reply code). It is no 276 longer possible to determine whether or not this message satisfies 277 the ADMD's list of authorized third-party signers. The Verifier 278 SHOULD stop processing and defer the message for later processing, 279 such as requesting temporary failure code from the MTA. 281 If all queries are completed and return either NXDOMAIN or NOERROR 282 with no answers, then the Signer was not authorized by the ADMD. 284 A valid ATPS reply consists of a sequence of tag-value pairs as 285 described in Section 3.2 of [DKIM]. The following tag and value is 286 the only one currently supported in ATPS records: 288 v: Version (plain-text; REQUIRED) This tag defines the version of 289 this specification that applies to the ATPS record. It MUST have 290 the value "ATPS1". ABNF: 292 atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31 293 ; FWS is defined in [DKIM] 295 5. Interpretation 297 For each DKIM signature that verifies (see Section 6 of [DKIM]), if a 298 Verifier succeeds in confirming that the Author's ADMD authorized the 299 ATPS Signer using this protocol, then the Verifier SHOULD evaluate 300 the message as though it contained a valid signature from the 301 Author's ADMD. It MAY also independently evaluate the ATPS Signer 302 when determining message disposition. 304 This assertion is based on the fact that the ADMD explicitly endorsed 305 the ATPS Signer. Therefore, a module assessing reputation that is 306 based on DKIM signature verification SHOULD apply the reputation of 307 the Author's ADMD domain instead of, or in addition to, that of the 308 ATPS Signer domain. 310 6. Relationship to ADSP 312 [ADSP] defined a protocol by which the owner of an Author Domain can 313 advertise a request to message receivers that messages bearing no 314 valid author signature be treated with suspicion or even discarded. 316 A Verifier implementing both ADSP and ATPS MUST test ATPS first. If 317 ATPS indicates a valid delegation, the verifier MUST act, with 318 respect to ADSP, as though the message has a valid Author Domain 319 Signature (because that's what the delegation means), and no ADSP 320 test is required. 322 7. Experiment Process 324 The working group that developed DKIM considered a third-party 325 mechanism such as this one to be controversial, in terms of need and 326 practicality, and decided that an alternative mechanism was suffient. 327 However, this was not based on actual experience as there is no 328 specific history on this question. Thus, this experiment was 329 devised. 331 The experimental protocol described here has been implemented as an 332 extension to DKIM in two software products, one of which is open 333 source and seeing increasingly wide use. It is included there to 334 allow customers of those systems to make use of it if they believe 335 such third party assertions are useful to the overall DKIM mechanism. 336 Further adoption as part of the experiment is welcome and encouraged. 338 Use of the protocol and anecdotes of how it affects the overall DKIM 339 experience will be collected by those implementers and the author of 340 this memo. Those participating in the experiment are also advised to 341 observe and report the impact of what is discussed in Section 9.3, 342 especially with respect to MTA latency that may be introduced. 344 If the response is substantial and positive, advancement along the 345 Standards Track might be warranted. 347 8. IANA Considerations 349 Section 8.2, Section 8.3, and Section 8.4, below, specify requested 350 IANA actions. Section 8.1 needs no IANA action at this time. 352 8.1. ATPS Tag Registry 354 NOTE: NO IANA ACTION IS REQUIRED BY THIS SECTION AT THIS TIME. [RFC 355 EDITOR: Please remove this paragraph before publication.] 357 If this specification is ever moved to the Standards Track, IANA will 358 then be asked to create an Authorized Third Party Signature (ATPS) 359 Tag Registry to enumerate the tags that are valid for use in ATPS 360 records. This section documents that future registry in advance. 362 New registrations or updates MUST be published in accordance with the 363 "Specification Required" guidelines described in [IANA]. Such 364 registry changes MUST contain the following information: 366 1. Name of the tag being registered or updated 368 2. The document where the specification is created or updated 370 3. The status of the tag, one of "current" (tag is in current use), 371 "deprecated" (tag is in current use but its use is discouraged), 372 or "historic" (tag is no longer in use) 374 The registry's sole initial entry is: 376 +-----+--------------+---------+ 377 | Tag | Specified In | Status | 378 +-----+--------------+---------+ 379 | v | [this memo] | current | 380 +-----+--------------+---------+ 382 8.2. Email Authentication Method Name Registry Update 384 The following is to be added to the Email Authentication Methods 385 Registry (in the Email Authentication Parameters group) established 386 by [AUTHRES] as per [IANA]: 388 Method: dkim-atps 390 Defined In: [THIS MEMO] 392 ptype: header 394 property: from 396 value: contents of the [MAIL] From: header field, with comments 397 removed 399 8.3. Email Authentication Result Name Registry Update 401 The following are to be added to the Email Authentication Result 402 Names Registry (in the Email Authentication Parameters group) 403 established by [AUTHRES] as per [IANA]: 405 Code: none 407 Existing/New Code: existing 408 Defined In: [AUTHRES] 410 Auth Method: dkim-atps 412 Meaning: No valid DKIM signatures were found on the message bearing 413 "atps" tags. 415 Code: pass 417 Existing/New Code: existing 419 Defined In: [AUTHRES] 421 Auth Method: dkim-atps 423 Meaning: An ATPS evaluation was performed and a valid signature from 424 an authorized third-party was found on the message. 426 Code: fail 428 Existing/New Code: existing 430 Defined In: [AUTHRES] 432 Auth Method: dkim-atps 434 Meaning: All valid DKIM signatures bearing an "atps" tag either did 435 not reference a domain name found in the RFC5322.From field, or 436 the ATPS test(s) performed failed to confirm a third-party 437 authorization. 439 Code: temperror 441 Existing/New Code: existing 443 Defined In: [AUTHRES] 445 Auth Method: dkim-atps 447 Meaning: An ATPS evaluation could not be completed due to some error 448 that is likely transient in nature, such as a temporary DNS error. 449 A later attempt might produce a final result. 451 Code: permerror 452 Existing/New Code: existing 454 Defined In: [AUTHRES] 456 Auth Method: dkim-atps 458 Meaning: An ATPS evaluation could not be completed due to some error 459 that is not likely transient in nature, such as a permanent DNS 460 error. A later attempt is unlikely to produce a final result. 462 8.4. DKIM-Signature Tag Specification Registry 464 The following are to be added to the DKIM-Signature Tag Speficication 465 Registry (in the DomainKeys Identifie Mail (DKIM) Parameters group) 466 established by [DKIM] as per [IANA]: 468 +-------+-------------+---------+ 469 | TYPE | REFERENCE | STATUS | 470 +-------+-------------+---------+ 471 | atps | [THIS MEMO] | current | 472 +-------+-------------+---------+ 473 | atpsh | [THIS MEMO] | current | 474 +-------+-------------+---------+ 476 9. Security Considerations 478 This section discusses potential security issues related to this 479 experimental protocol. 481 9.1. False Privacy 483 The fact that the authorized third-party domain name is hashed and 484 then encoded with base32 might give some the false sense that the 485 relationship between the two parties is somehow protected. This is 486 not the case. Indeed, the very purpose of this protocol is to make 487 it possible for such relationships to be discovered, so such an 488 obscuration would make that process more difficult without a shared 489 secret delivered out-of-band to message verifiers (which also adds 490 further complexity. Rather, the hash and encode steps are done 491 merely to convert any third-party domain name to a fixed width in the 492 construction of the DNS query. 494 9.2. Transient Security Failures 496 Approving a third party signer exposes the ADMD to the risk that the 497 third party signer becomes compromised and then begins to sign 498 malicious or nuisance messages on behalf of the ADMD. This can 499 obviously reflect negatively on the ADMD, and the impact of this can 500 become more severe as automated domain reputation systems are 501 developed and deployed. Thorough vetting and monitoring practices by 502 ADMDs of third party signers will likely need to become the norm. 504 9.3. Load on the DNS 506 A Verifier participating in DKIM, ADSP and ATPS will now issue a 507 number of TXT queries to the DNS equal to as many as one (for the 508 ADSP query) plus the number of signatures on the message (one for 509 each key that is to be verified) plus the number of signatures that 510 validated which also bear an "atps" tag. This is in addition to any 511 PTR and A queries the MTA might issue at the time the actual message 512 relaying or delivery is initiated. Obviously this can be burdensome 513 on the DNS at both ends, and waiting for that number of queries to 514 return when they are issued in parallel could trigger timeouts in the 515 MTA. 517 An alternative to this that has not yet been explored is the storage 518 of the ATPS data at a specific URL tied to the Author's domain name. 519 This would alleviate pressure on the DNS at the expense of requiring 520 the ADMD to operate a web server (which has its own security 521 implications) and the addition of the establishment of a TCP 522 connection. Moreover, the Verifier would be well advised to 523 implement caching of this data to prevent ATPS from being used as a 524 denial-of-service vector. 526 See Section 8.5 of [DKIM] for further discussion of DNS-related 527 issues. 529 10. References 531 10.1. Normative References 533 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax 534 Specifications: ABNF", STD 68, RFC 5234, January 2008. 536 [AUTHRES] Kucherawy, M., "Message Header Field for Indicating 537 Message Authentication Status", RFC 5451, April 2009. 539 [BASE32] Josefsson, S., "The Base16, Base32, and Base64 Data 540 Encodings", RFC 4648, October 2006. 542 [DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, 543 Ed., "DomainKeys Identified Mail (DKIM) Signatures", 544 RFC 6376, September 2011. 546 [DNS] Mockapetris, P., "Domain names - implementation and 547 specification", STD 13, RFC 1035, November 1987. 549 [EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, 550 October 2008. 552 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 553 Requirement Levels", BCP 14, RFC 2119, March 1997. 555 [MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, 556 October 2008. 558 10.2. Informative References 560 [ADSP] Allman, E., Fenton, J., Delany, M., and J. Levine, 561 "DomainKeys Identified Mail (DKIM) Author Domain 562 Signing Practices (ADSP)", RFC 5617, August 2009. 564 [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing 565 an IANA Considerations Section in RFCs", BCP 26, 566 RFC 5226, May 2008. 568 Appendix A. Example Query and Reply 570 This section presents an example of the use of this protocol to query 571 for a third-party authorization and discusses the interpretation of 572 the result. 574 Presume a message for which the RFC5322.From domain is "example.com", 575 and it bears two valid signatures, from "one.example.net" and from 576 "two.example.net", each with an "atps" tag whose value is 577 "example.com", and no "atpsh" tag is present in either. The 578 following actions are taken: 580 1. A SHA1 hash of "one.example.net" is computed and then converted 581 to printable form using base32 encoding, resulting in the string 582 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6". 584 2. A TXT query is issued to 585 "QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com". 587 3. If a valid reply arrives, the algorithm stops with [AUTHRES] 588 result "pass". If a DNS error code other than NXDOMAIN is 589 returned, the algorithm stops with a result of "temperror" or 590 "permerror" as appropriate. 592 4. A SHA1 hash of "two.example.net" is computed and then converted 593 to printable form using base32 encoding, resulting in the string 594 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX". 596 5. A TXT query is issued to 597 "ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com". 599 6. If a valid reply arrives, the algorithm stops with [AUTHRES] 600 result "pass". If a DNS error code other than NXDOMAIN is 601 returned, the algorithm stops with a result of "temperror" or 602 "permerror" as appropriate. 604 7. As there are no valid signatures left to test, the algorithm 605 stops with an "unknown" result. 607 Appendix B. Acknowledgements 609 The author wishes to acknowledge Dave Crocker, Frank Ellermann, Mark 610 Martinec and Phil Pennock for their review and constructive criticism 611 of this proposal. 613 The author also wishes to acknowledge Doug Otis and Daniel Black for 614 their original draft upon which this work was based. 616 Author's Address 618 Murray S. Kucherawy 619 Cloudmark, Inc. 620 128 King St., 2nd Floor 621 San Francisco, CA 94107 622 US 624 Phone: +1 415 946 3800 625 EMail: msk@cloudmark.com