idnits 2.17.1 draft-ietf-dkim-rfc4871-errata-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document updates RFC4871, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 26, 2009) is 5416 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'FWS' is mentioned on line 378, but not defined ** Obsolete normative reference: RFC 3490 (Obsoleted by RFC 5890, RFC 5891) ** Obsolete normative reference: RFC 4871 (Obsoleted by RFC 6376) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DKIM D. Crocker, Ed. 3 Internet-Draft Brandenburg InternetWorking 4 Updates: RFC4871 June 26, 2009 5 (if approved) 6 Intended status: Standards Track 7 Expires: December 28, 2009 9 RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update 10 draft-ietf-dkim-rfc4871-errata-07 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on December 28, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 This updates RFC 4871, DomainKeys Identified Mail (DKIM) Signatures. 59 Specifically the document clarifies the nature, roles and 60 relationship of the two DKIM identifier tag values that are 61 candidates for payload delivery to a receiving processing module. 62 The Update is in the style of an Errata entry, albeit a rather long 63 one. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. RFC 4871 Abstract . . . . . . . . . . . . . . . . . . . . . . 4 69 3. RFC4871 Section 1 Introduction . . . . . . . . . . . . . . . 5 70 4. RFC4871 Section 2.7 Identity . . . . . . . . . . . . . . . . 5 71 5. RFC4871 Section 2.8 Identifier . . . . . . . . . . . . . . . 5 72 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) . . . . 5 73 7. RFC4871 Section 2.10 Agent or User Identifier (AUID) . . . . 6 74 8. RFC4871 Section 2.11 Identity Assessor . . . . . . . . . . . 6 75 9. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 7 76 10. RFC4871 Section 3.5 The DKIM-Signature Header Field . . . . . 8 77 11. RFC4871 Section 3.8 Signing by Parent Domains . . . . . . . . 10 78 12. RFC4871 Section 3.9 Relationship Between SDID and AUID . . . 10 79 13. RFC4871 Section 6.3 Interpret Results/Apply Local Policy . . 11 80 14. RFC4871 Section 6.3 Interpret Results/Apply Local Policy . . 12 81 15. RFC4871 Appendix D. MUA Considerations . . . . . . . . . . . 12 82 16. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 84 18. Normative References . . . . . . . . . . . . . . . . . . . . . 13 85 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 1. Introduction 90 About the purpose for DKIM, [RFC4871] states: 92 The ultimate goal of this framework is to permit a signing domain 93 to assert responsibility for a message, thus protecting message 94 signer identity... 96 Hence, DKIM has a signer that produces a signed message, a verifier 97 that confirms the signature and an assessor that consumes the 98 validated signing domain. So the simple purpose of DKIM is to 99 communicate an identifier to a receive-side assessor module. The 100 identifier is in the form of a domain name that refers to a 101 responsible identity. For DKIM to be interoperable and useful, 102 signer and assessor must share the same understanding of the details 103 about the identifier. 105 However the RFC4871 specification defines two, potentially different 106 identifiers that are carried in the DKIM-Signature: header field, d= 107 and i=. Either might be delivered to a receiving processing module 108 that consumes validated payload. The DKIM specification fails to 109 clearly define which is the "payload" to be delivered to a consuming 110 module, versus what is internal and merely in support of achieving 111 payload delivery. 113 This currently leaves signers and assessors with the potential for 114 making different interpretations between the two identifiers and may 115 lead to interoperability problems. A signer could intend one to be 116 used for assessment, and have a different intent in setting the value 117 in the other. However the verifier might choose the wrong value to 118 deliver to the assessor, thereby producing an unintended (and 119 inaccurate) assessment. 121 This update resolves that confusion. It defines additional, semantic 122 labels for the two values, clarifies their nature and specifies their 123 relationship. More specifically, it clarifies that the identifier 124 intended for delivery to the assessor -- such as one that consults a 125 white list -- is the value of the "d=" tag. However, this does not 126 prohibit message filtering engines from using the "i=" tag, or any 127 other information in the message's header, for filtering decisions. 129 For signers and verifiers that have been using the i= tag as the 130 primary value that is delivered to the assessor, a software change to 131 using the d= tag is intended. 133 So, this Update clarifies the formal interface to DKIM, after 134 signature verification has been performed. It distinguishes DKIM's 135 internal signing and verification activity, from its standardized 136 delivery of data to that interface. 138 The focus of the Update is on the portion of DKIM that is much like 139 an API definition. If DKIM is implemented as a software library for 140 use by others, it needs to define what outputs are provided, that is, 141 what data that an application developer who uses the library can 142 expect to obtain as a result of invoking DKIM on a message. 144 This Update draft defines the output of that library to include the 145 yes/no result of the verification and the "d=" value. In other 146 words, it says what (one) identifier was formally specified for use 147 by the signer and whether the use of that identifier has been 148 validated. For a particular library, other information can be 149 provided at the discretion of the library developer, since developers 150 of assessors -- these are the consumers of the DKIM library -- well 151 might want more information than the standardized two pieces of 152 information. However that standardized set is the minimum that is 153 required to be provided to a consuming module, in order to be able to 154 claim that the library is DKIM compliant. 156 This does not state what the implicit value of "i=" is, relative to 157 "d=". In this context, that fact is irrelevant. 159 Another example is the difference between the socket interface to TCP 160 versus the TCP protocol itself. There is the activity within the 161 protocol stack, and then there is the activity within in the software 162 libraries that are actually used. 164 NOTE: The text provided here updates [RFC4871]. All references and 165 all appearances of RFC-2119 keywords are replacing text in RFC 166 4871. Hence those references are in that document and are not 167 needed here. 169 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 170 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 171 document are to be interpreted as described in [RFC2119] 173 2. RFC 4871 Abstract 175 Original Text: 177 The ultimate goal of this framework is to permit a signing domain 178 to assert responsibility for a message, 180 Corrected Text: 182 The ultimate goal of this framework is to permit a person, role or 183 organization that owns the signing domain to assert responsibility 184 for a message, 186 3. RFC4871 Section 1 Introduction 188 Original Text: 190 ...permitting a signing domain to claim responsibility 192 Corrected Text: 194 permitting a person, role or organization that owns the signing 195 domain to claim responsibility 197 4. RFC4871 Section 2.7 Identity 199 Original Text: 201 (None. New section. Additional text.) 203 Corrected Text: 205 A person, role or organization. In the context of DKIM, examples 206 include author, author's organization, an ISP along the handling 207 path, an independent trust assessment service, and a mailing list 208 operator. 210 5. RFC4871 Section 2.8 Identifier 212 Original Text: 214 (None. New section. Additional text.) 216 Corrected Text: 218 A label that refers to an identity. 220 6. RFC4871 Section 2.9 Signing Domain Identifier (SDID) 221 Original Text: 223 (None. New section. Additional text.) 225 Corrected Text: 227 A single domain name that is the mandatory payload output of DKIM 228 and that refers to the identity claiming responsibility for 229 introduction of a message into the mail stream. For DKIM 230 processing, the name has only basic domain name semantics; any 231 possible owner-specific semantics are outside the scope of DKIM. 232 It is specified in section 3.5. 234 7. RFC4871 Section 2.10 Agent or User Identifier (AUID) 236 Original Text: 238 (None. New section. Additional text.) 240 Corrected Text: 242 A single identifier that refers to the agent or user on behalf of 243 whom the SDID has taken responsibility. The AUID comprises a 244 domain name and an optional . The domain name is the 245 same as that used for the SDID or is a sub-domain of it. For DKIM 246 processing, the domain name portion of the AUID has only basic 247 domain name semantics; any possible owner-specific semantics are 248 outside the scope of DKIM. It is specified in section 3.5. 250 8. RFC4871 Section 2.11 Identity Assessor 252 Original Text: 254 (None. New section. Additional text.) 256 Corrected Text: 258 A module that consumes DKIM's mandatory payload, which is the 259 responsible Signing Domain Identifier (SDID). The module is 260 dedicated to the assessment of the delivered identifier. Other 261 DKIM (and non-DKIM) values can also be delivered to this module as 262 well as to a more general message evaluation filtering engine. 263 However, this additional activity is outside the scope of the DKIM 264 signature specification. 266 9. RFC4871 Section 3.5 The DKIM-Signature Header Field 268 Original Text: 270 d= The domain of the signing entity (plain-text; REQUIRED). This is 271 the domain that will be queried for the public key. This domain 272 MUST be the same as or a parent domain of the "i=" tag (the 273 signing identity, as described below), or it MUST meet the 274 requirements for parent domain signing described in Section 3.8. 275 When presented with a signature that does not meet these 276 requirement, verifiers MUST consider the signature invalid. 278 Internationalized domain names MUST be encoded as described in 279 [RFC3490]. 281 ABNF: 283 sig-d-tag = %x64 [FWS] "=" [FWS] domain-name 284 domain-name = sub-domain 1*("." sub-domain) 285 ; from RFC 2821 Domain, 286 but excluding address-literal 288 Corrected Text: 290 d= 292 Specifies the SDID claiming responsibility for an introduction 293 of a message into the mail stream (plain-text; REQUIRED). 294 Hence the SDID value is used to form the query for the public 295 key. The SDID MUST correspond to a valid DNS name under which 296 the DKIM key record is published. The conventions and 297 semantics used by a signer to create and use a specific SDID 298 are outside the scope of the DKIM Signing specification, as is 299 any use of those conventions and semantics. When presented 300 with a signature that does not meet these requirements, 301 verifiers MUST consider the signature invalid. 303 Internationalized domain names MUST be encoded as described in 304 [RFC3490]. 306 ABNF: 308 sig-d-tag = %x64 [FWS] "=" [FWS] domain-name 309 domain-name = sub-domain 1*("." sub-domain) 310 ; from RFC 5321 Domain, 311 but excluding address-literal 313 10. RFC4871 Section 3.5 The DKIM-Signature Header Field 315 Original Text: 317 i= Identity of the user or agent (e.g., a mailing list manager) on 318 behalf of which this message is signed (dkim-quoted-printable; 319 OPTIONAL, default is an empty Local-part followed by an "@" 320 followed by the domain from the "d=" tag). The syntax is a 321 standard email address where the Local-part MAY be omitted. The 322 domain part of the address MUST be the same as or a subdomain of 323 the value of the "d=" tag. 325 Internationalized domain names MUST be converted using the steps 326 listed in Section 4 of [RFC3490] using the "ToASCII" function. 328 ABNF: 330 sig-i-tag = %x69 [FWS] "=" [FWS] 331 [ Local-part ] "@" domain-name 333 INFORMATIVE NOTE: The Local-part of the "i=" tag is optional 334 because in some cases a signer may not be able to establish a 335 verified individual identity. In such cases, the signer may 336 wish to assert that although it is willing to go as far as 337 signing for the domain, it is unable or unwilling to commit 338 to an individual user name within their domain. It can do so 339 by including the domain part but not the Local-part of the 340 identity. 342 INFORMATIVE DISCUSSION: This document does not require the value 343 of the "i=" tag to match the identity in any message header 344 fields. This is considered to be a verifier policy issue. 345 Constraints between the value of the "i=" tag and other 346 identities in other header fields seek to apply basic 347 authentication into the semantics of trust associated with a 348 role such as content author. Trust is a broad and complex 349 topic and trust mechanisms are subject to highly creative 350 attacks. The real-world efficacy of 351 bindings between the "i=" value and other identities is not 352 well established, nor is its vulnerability to subversion by 353 an attacker. Hence reliance on the use of these options 354 should be strictly limited. In particular, it is not at all 355 clear to what extent a typical end-user recipient can rely on 356 any assurances that might be made by successful use of the 357 "i=" options. 359 Corrected Text: 361 i= 363 The Agent or User Identifier (AUID) on behalf of which the SDID 364 is taking responsibility (dkim-quoted-printable; OPTIONAL, 365 default is an empty Local-part followed by an "@" followed by 366 the domain from the "d=" tag). 368 The syntax is a standard email address where the Local-part MAY 369 be omitted. The domain part of the address MUST be the same 370 as, or a subdomain of the value of, the "d=" tag. 372 Internationalized domain names MUST be converted using the 373 steps listed in Section 4 of [RFC3490] using the "ToASCII" 374 function. 376 ABNF: 378 sig-i-tag = %x69 [FWS] "=" [FWS] 379 [ Local-part ] "@" domain-name 381 The AUID is specified as having the same syntax as an email 382 address, but is not required to have the same semantics. 383 Notably, the domain name is not required to be registered in 384 the DNS -- so it might not resolve in a query -- and the Local- 385 part MAY be drawn from a namespace that does not contain the 386 user's mailbox. The details of the structure and semantics for 387 the namespace are determined by the Signer. Any knowledge or 388 use of those details by verifiers or assessors is outside the 389 scope of the DKIM Signing specification. The Signer MAY choose 390 to use the same namespace for its AUIDs as its users' email 391 addresses, or MAY choose other means of representing its users. 392 However, the signer SHOULD use the same AUID for each message 393 intended to be evaluated as being within the same sphere of 394 responsibility, if it wishes to offer receivers the option of 395 using the AUID as a stable identifier that is finer grained 396 than the SDID. 398 INFORMATIVE NOTE: The Local-part of the "i=" tag is optional 399 because in some cases a signer may not be able to establish a 400 verified individual identity. In such cases, the signer might 401 wish to assert that although it is willing to go as far as 402 signing for the domain, it is unable or unwilling to commit to 403 an individual user name within their domain. It can do so by 404 including the domain part but not the Local-part of the 405 identity. 407 11. RFC4871 Section 3.8 Signing by Parent Domains 409 Original Text: 411 e.g., a key record for the domain example.com can be used to verify 412 messages where the signing identity ("i=" tag of the signature) is 413 sub.example.com, or even sub1.sub2.example.com. In order to limit 414 the capability of such keys when this is not intended, the "s" flag 415 may be set in the "t=" tag of the key record to constrain the 416 validity of the record to exactly the domain of the signing identity. 417 If the referenced key record contains the "s" flag as part of the 418 "t=" tag, the domain of the signing identity ("i=" flag) MUST be the 419 same as that of the d= domain. If this flag is absent, the domain of 420 the signing identity MUST be the same as, or a subdomain of, the d= 421 domain. 423 Corrected Text: 425 ...for example, a key record for the domain example.com can be 426 used to verify messages where the AUID ("i=" tag of the signature) 427 is sub.example.com, or even sub1.sub2.example.com. In order to 428 limit the capability of such keys when this is not intended, the 429 "s" flag MAY be set in the "t=" tag of the key record, to 430 constrain the validity of the domain of the AUID. If the 431 referenced key record contains the "s" flag as part of the "t=" 432 tag, the domain of the AUID ("i=" flag) MUST be the same as that 433 of the SDID (d=) domain. If this flag is absent, the domain of 434 the AUID MUST be the same as, or a subdomain of, the SDID. 436 12. RFC4871 Section 3.9 Relationship Between SDID and AUID 438 Original Text: (None. New section. Additional text.) 440 Corrected Text: 442 DKIM's primary task is to communicate from the Signer to a 443 recipient-side Identity Assessor a single Signing Domain 444 Identifier (SDID) that refers to a responsible identity. DKIM MAY 445 optionally provide a single responsible Agent or User Identifier 446 (AUID). 448 Hence, DKIM's mandatory output to a receive-side Identity Assessor 449 is a single domain name. Within the scope of its use as DKIM 450 output, the name has only basic domain name semantics; any 451 possible owner-specific semantics are outside the scope of DKIM. 452 That is, within its role as a DKIM identifier, additional 453 semantics cannot be assumed by an Identity Assessor. 455 A receive-side DKIM verifier MUST communicate the Signing Domain 456 Identifier (d=) to a consuming Identity Assessor module and MAY 457 communicate the Agent or User Identifier (i=) if present. 459 To the extent that a receiver attempts to intuit any structured 460 semantics for either of the identifiers, this is a heuristic 461 function that is outside the scope of DKIM's specification and 462 semantics. Hence it is relegated to a higher-level service, such 463 as a delivery handling filter that integrates a variety of inputs 464 and performs heuristic analysis of them. 466 INFORMATIVE DISCUSSION: This document does not require the value 467 of the SDID or AUID to match the identifier in any other message 468 header field. This requirement is, instead, an assessor policy 469 issue. The purpose of such a linkage would be to authenticate the 470 value in that other header field. This, in turn, is the basis for 471 applying a trust assessment based on the identifier value. Trust 472 is a broad and complex topic and trust mechanisms are subject to 473 highly creative attacks. The real-world efficacy of any but the 474 most basic bindings between the SDID or AUID and other identities 475 is not well established, nor is its vulnerability to subversion by 476 an attacker. Hence reliance on the use of such bindings should be 477 strictly limited. In particular, it is not at all clear to what 478 extent a typical end-user recipient can rely on any assurances 479 that might be made by successful use of the SDID or AUID. 481 13. RFC4871 Section 6.3 Interpret Results/Apply Local Policy 483 Original Text: 485 It is beyond the scope of this specification to describe what actions 486 a verifier system should make, but an authenticated email presents an 487 opportunity to a receiving system that unauthenticated email cannot. 488 Specifically, an authenticated email creates a predictable identifier 489 by which other decisions can reliably be managed, such as trust and 490 reputation. Conversely, unauthenticated email lacks a reliable 491 identifier that can be used to assign trust and reputation. 493 Corrected Text: 495 It is beyond the scope of this specification to describe what 496 actions an Identity Assessor can make, but mail carrying a 497 validated SDID presents an opportunity to an Identity Assessor 498 that unauthenticated email does not. Specifically, an 499 authenticated email creates a predictable identifier by which 500 other decisions can reliably be managed, such as trust and 501 reputation. 503 14. RFC4871 Section 6.3 Interpret Results/Apply Local Policy 505 Original Text: 507 Once the signature has been verified, that information MUST be 508 conveyed to higher-level systems (such as explicit allow/whitelists 509 and reputation systems) and/or to the end user. If the message is 510 signed on behalf of any address other than that in the From: header 511 field, the mail system SHOULD take pains to ensure that the actual 512 signing identity is clear to the reader. 514 Corrected Text: 516 Once the signature has been verified, that information MUST be 517 conveyed to the Identity Assessor (such as an explicit allow/ 518 whitelist and reputation system) and/or to the end user. If the 519 SDID is not the same as the address in the From: header field, the 520 mail system SHOULD take pains to ensure that the actual SDID is 521 clear to the reader. 523 15. RFC4871 Appendix D. MUA Considerations 525 Original Text: The tendency is to have the MUA highlight the 526 address associated with this signing identity in some way, in an 527 attempt to show the user the address from which the mail was sent. 529 Corrected Text: The tendency is to have the MUA highlight the SDID, 530 in an attempt to show the user the identity that is claiming 531 responsibility for the message. 533 16. Security Considerations 535 This Update clarifies core details about DKIM's payload. As such it 536 affects interoperability, semantic characterization, and the 537 expectations for the identifiers carried with a DKIM signature. 538 Clarification of these details is likely to limit misinterpretation 539 of DKIM's semantics. Since DKIM is fundamentally a security 540 protocol, this should improve its security characteristics. 542 17. IANA Considerations 544 This document has no actions for IANA. 546 18. Normative References 548 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 549 Requirement Levels", BCP 14, RFC 2119, March 1997. 551 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 552 "Internationalizing Domain Names in Applications (IDNA)", 553 RFC 3490, March 2003. 555 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 556 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 557 Signatures", RFC 4871, May 2007. 559 Appendix A. Acknowledgements 561 This document was initially formulated by an ad hoc design team, 562 comprising: Jon Callas, D. Crocker, J. D. Falk, Michael Hammer, Tony 563 Hansen, Murray Kucherawy, John Levine, Jeff Macdonald, Ellen Siegel 564 and Wietse Venema. The final version of the document was developed 565 through vigorous discussion in the IETF DKIM working group. 567 Author's Address 569 D. Crocker (editor) 570 Brandenburg InternetWorking 572 Phone: +1.408.246.8253 573 Email: dcrocker@bbiw.net