idnits 2.17.00 (12 Aug 2021) /tmp/idnits41845/draft-crocker-dkim-rfc4871bis-doseta-00.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document obsoletes RFC4871, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document obsoletes RFC5672, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 640 has weird spacing: '... email elec...' -- The document date (January 14, 2011) is 4138 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: None ---------------------------------------------------------------------------- == Missing Reference: 'FWS' is mentioned on line 675, but not defined == Unused Reference: 'RFC5672' is defined on line 828, but no explicit reference was found in the text -- No information found for draft-ietf-DKIM-DOSETA - is the name correct? ** Obsolete normative reference: RFC 4234 (ref. 'RFC5234') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 5672 (Obsoleted by RFC 6376) -- Obsolete informational reference (is this intentional?): RFC 4870 (Obsoleted by RFC 4871) -- Obsolete informational reference (is this intentional?): RFC 4871 (Obsoleted by RFC 6376) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 7 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 Obsoletes: 4871, 5672 (if approved) M. Kucherawy, Ed. 5 Intended status: Standards Cloudmark 6 Expires: July 18, 2011 January 14, 2011 8 DomainKeys Identified Mail (DKIM) Signatures - Over DOSETA 9 draft-crocker-dkim-rfc4871bis-doseta-00 11 Abstract 13 DomainKeys Identified Mail (DKIM) permits a person, role, or 14 organization that owns the signing domain to claim some 15 responsibility for a message by associating the domain with the 16 message. This can be an author's organization, an operational relay 17 or one of their agents. DKIM separates the question of the identity 18 of the signer of the message from the purported author of the 19 message. Assertion of responsibility is validated through a 20 cryptographic signature and querying the signer's domain directly to 21 retrieve the appropriate public key. Message transit from author to 22 recipient is through relays that typically make no substantive change 23 to a message or its content and thus preserve the DKIM signature. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 18, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Signing Identity {rfc4871bis-02 1.1} . . . . . . . . . . . 4 61 1.2. Terminology and Definitions . . . . . . . . . . . . . . . 4 62 2. Signing and Verifying Protocol {added} . . . . . . . . . . . . 5 63 3. Extensions to DOSETA Template {rfc4871bis-02 - adapted 64 for Doseta overlay} . . . . . . . . . . . . . . . . . . . . . 6 65 3.1. Signature Data Structure {rfc4871bis-02 3.5, subset} . . . 6 66 3.2. Relationship between SDID and AUID {rfc4871bis-02 3.9} . . 13 67 3.3. Stored Key Data {rfc4871bis-02 3.6.1, subset} . . . . . . 14 68 4. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 16 69 4.1. Security Considerations {rfc4871bis-02 8, subset} . . . . 16 70 4.2. IANA Considerations {rfc4871bis-02 7, subset} . . . . . . 17 71 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 72 5.1. Normative References . . . . . . . . . . . . . . . . . . . 19 73 5.2. Informative References . . . . . . . . . . . . . . . . . . 19 74 Appendix A. MUA Considerations {rfc4871bis-02 D} . . . . . . . . 20 75 Appendix B. End-to-End Scenario Example {rfc4871bis-02 A} . . . . 21 76 B.1. The User Composes an Email . . . . . . . . . . . . . . . . 21 77 B.2. The Email is Signed . . . . . . . . . . . . . . . . . . . 21 78 B.3. The Email Signature is Verified . . . . . . . . . . . . . 22 79 Appendix C. Types of Use {rfc4871bis-02 B} . . . . . . . . . . . 23 80 C.1. Alternate Submission Scenarios . . . . . . . . . . . . . . 24 81 C.2. Alternate Delivery Scenarios . . . . . . . . . . . . . . . 26 82 Appendix D. Acknowledgements . . . . . . . . . . . . . . . . . . 28 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 85 1. Introduction 87 DomainKeys Identified Mail (DKIM) permits a person, role, or 88 organization to claim some responsibility for a message by 89 associating a domain name [RFC1034] with the message [RFC5322]. This 90 can be an author's organization, an operational relay or one of their 91 agents. Assertion of responsibility is validated through a 92 cryptographic signature and querying the signer's domain directly to 93 retrieve the appropriate public key. Message transit from author to 94 recipient is through relays that typically make no substantive change 95 to the message content and thus preserve the DKIM signature. A 96 message can contain multiple signatures, from the same or different 97 organizations involved with the message. 99 The DKIM service is described in detail in [RFC5585] and [RFC5863]. 101 This version of DKIM is based on a split between DKIM-specific 102 details, versus an underlying component mechanism, called DOSETA, 103 that can be used for other services. [I-D.Doseta]. 105 NOTE: Much of the text for this draft is taken from the DKIM 106 working group draft-ietf-DKIM-rfc4871bis-02 revision. Sections 107 in this document cross reference their source with the 108 notation: 109 {rfc4871bis-02 xx} 110 where "xx" indicates the section number. It might also 111 indicate that a subset is taken, such as when a portion is 112 applied to the DKIM-over-DOSETA draft and a portion to the 113 DOSETA draft. In some cases the base text also has been 114 enhanced. 116 The approach taken by DKIM differs from previous approaches to 117 message signing (for example., Secure/Multipurpose Internet Mail 118 Extensions (S/MIME) [RFC1847], OpenPGP [RFC4880]) in that: 120 o the message signature is written as a message header field so that 121 neither human recipients nor existing MUA (Mail User Agent) 122 software is confused by signature-related content appearing in the 123 message body; 125 o there is no dependency on public and private key pairs being 126 issued by well-known, trusted certificate authorities; 128 o there is no dependency on the deployment of any new Internet 129 protocols or services for public key distribution or revocation; 131 o signature verification failure does not force rejection of the 132 message; 134 o no attempt is made to include encryption as part of the mechanism; 136 o message archiving is not a design goal. 138 DKIM: 140 o is compatible with the existing email infrastructure and 141 transparent to the fullest extent possible; 143 o requires minimal new infrastructure; 145 o can be implemented independently of clients in order to reduce 146 deployment time; 148 o can be deployed incrementally; 150 o allows delegation of signing to third parties. 152 1.1. Signing Identity {rfc4871bis-02 1.1} 154 DKIM separates the question of the identity of the signer of the 155 message from the purported author of the message. In particular, a 156 signature includes the identity of the signer. Verifiers can use the 157 signing information to decide how they want to process the message. 158 The signing identity is included as part of the signature header 159 field. 161 The signing identity specified by a DKIM signature is not required to 162 match an address in any particular header field because of the broad 163 methods of interpretation by recipient mail systems, including MUAs. 165 1.2. Terminology and Definitions 167 This specification incorporates the terminology defined in 168 [I-D.Doseta]. 170 Syntax descriptions use Augmented BNF (ABNF) [RFC5234]. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 Additional terminology: {rfc4871bis-02 #2, subset} 177 Signing Domain Identifier (SDID): This augments the definition 178 provided by DOSETA [I-D.Doseta]. A single domain name that is 179 the mandatory payload output of DKIM and that refers to the 180 identity claiming responsibility for introduction of a message 181 into the mail stream. For DKIM processing, the name has only 182 basic domain name semantics; any possible owner-specific 183 semantics are outside the scope of DKIM. It is specified in 184 Section 3.1. 186 Agent or User Identifier (AUID): A single identifier that refers 187 to the agent or user on behalf of whom the Signing Domain 188 Identifier (SDID) has taken responsibility. The AUID comprises 189 a domain name and an optional . The domain name is 190 the same as that used for the SDID or is a sub-domain of it. 191 For DOSETA processing, the domain name portion of the AUID has 192 only basic domain name semantics; any possible owner-specific 193 semantics are outside the scope of DOSETA. It is specified in 194 Section 3.1 . 196 Identity Assessor: This augments the definition of Assessor in 197 [I-D.Doseta]. A module that consumes DOSETA's mandatory 198 payload, which is the responsible Signing Domain Identifier 199 (SDID). The module is dedicated to the assessment of the 200 delivered identifier. Other DOSETA (and non-DOSETA) values can 201 also be delivered to this module as well as to a more general 202 message evaluation filtering engine. However, this additional 203 activity is outside the scope of the DKIM signature 204 specification. 206 2. Signing and Verifying Protocol {added} 208 DKIM uses the DOSETA "Generic Header/Content Signing Service 209 Template" [I-D.Doseta] as its base. 211 The DOSETA template specifies TEMPLATE information that is required 212 to tailor the signing service: 214 Signature Association: The DOSETA-Signature data are stored in a 215 DKIM-Signature header field that is part of the Header of the 216 message being signed. This contains all of the signature and 217 key-fetching data, per [I-D.Doseta]. 219 Semantics Signaling: The presence of a DKIM-Signature header 220 fields signals the use of DKIM. 222 Semantics: A DKIM signature means that the owner of the signing 223 domain is taking "some" responsibility for the message. Hence, 224 the payload, or output, of DKIM is: 226 + A validated domain name, specifically the d= parameter in 227 the DKIM-Signature header field 229 + An indication that its use has been validated 231 The nature and extent of a DKIM signer's responsibility can 232 vary widely and is beyond the scope of this specification. 234 Header/Content Mapping: DKIM maps the DOSETA Header processing 235 to an email header and the DOSETA Content to an email body, per 236 [RFC5322] 238 3. Extensions to DOSETA Template {rfc4871bis-02 - adapted for Doseta 239 overlay} 241 This section contains specifications that are added to the basic 242 DOSETA H/C Signing Template. 244 3.1. Signature Data Structure {rfc4871bis-02 3.5, subset} 246 These are DKIM-specific tags: ( 248 i= The Agent or User Identifier (AUID) on behalf of which the 249 SDID is taking responsibility (DOSETA-quoted-printable; 250 OPTIONAL, default is an empty followed by an "@" 251 followed by the domain from the "d=" tag). 253 The syntax is a standard email address where the 254 MAY be omitted. The domain part of the address MUST be the 255 same as, or a subdomain of, the value of the "d=" tag. 257 Internationalized domain names MUST be converted using the 258 steps listed in Section 4 of [RFC5890] using the "ToASCII" 259 function. 261 ABNF: 262 sig-i-tag = %x69 [FWS] "=" [FWS] 263 [ local-part ] "@" domain-name 265 The AUID is specified as having the same syntax as an email 266 address, but is not required to have the same semantics. 267 Notably, the domain name is not required to be registered in 268 the DNS -- so it might not resolve in a query -- and the 269 MAY be drawn from a namespace unrelated to any 270 mailbox. The details of the structure and semantics for the 271 namespace are determined by the Signer. Any knowledge or use 272 of those details by verifiers or assessors is outside the scope 273 of the DOSETA Signing specification. The Signer MAY choose to 274 use the same namespace for its AUIDs as its users' email 275 addresses or MAY choose other means of representing its users. 276 However, the signer SHOULD use the same AUID for each message 277 intended to be evaluated as being within the same sphere of 278 responsibility, if it wishes to offer receivers the option of 279 using the AUID as a stable identifier that is finer grained 280 than the SDID. 282 NOTE: The of the "i=" tag is optional because in 283 some cases a signer might not be able to establish a 284 verified individual identity. In such cases, the signer 285 might wish to assert that although it is willing to go as 286 far as signing for the domain, it is unable or unwilling to 287 commit to an individual user name within their domain. It 288 can do so by including the domain part but not the of the identity. 291 NOTE: Absent public standards for the semantics of an AUID, 292 an assessment based on AUID requires a non-standardized 293 basis. 295 NOTE: This specification does not require the value of the 296 "i=" tag to match the identity in any Header field. This is 297 considered to be an assessment-time policy issue. 298 Constraints between the value of the "i=" tag and other 299 identities in other Header fields might seek to apply basic 300 authentication into the semantics of trust associated with a 301 role such as content author. Trust is a broad and complex 302 topic and trust mechanisms are subject to highly creative 303 attacks. The real-world efficacy of any but the most basic 304 bindings between the "i=" value and other identities is not 305 well established, nor is its vulnerability to subversion by 306 an attacker. Hence reliance on the use of these options 307 needs to be strictly limited. In particular, it is not at 308 all clear to what extent a typical end-user recipient can 309 rely on any assurances that might be made by successful use 310 of the "i=" options. 312 l= Content length count (plain-text unsigned decimal integer; 313 OPTIONAL, default is entire Content). This tag informs the 314 verifier of the number of octets in the Content of the data 315 after canonicalization included in the cryptographic hash, 316 starting from 0 immediately following the CRLF preceding the 317 Content. This value MUST NOT be larger than the actual number 318 of octets in the canonicalized Content. 320 ABNF: 321 sig-l-tag = %x6c [FWS] "=" [FWS] 322 1*76DIGIT 324 NOTE: Use of the "l=" tag might allow display of fraudulent 325 content without appropriate warning to end users. The "l=" 326 tag is intended for increasing signature robustness when 327 sending to intermediaries that append data to Content, such 328 as mailing lists that both modify their content and do not 329 sign their messages. However, using the "l=" tag enables 330 attacks in which an intermediary with malicious intent 331 modifies a message to include content that solely benefits 332 the attacker. It is possible for the appended content to 333 completely replace the original content in the end 334 recipient's eyes and to defeat duplicate message detection 335 algorithms. Examples are described in Security 336 Considerations Section 4.1. To avoid this attack, signers 337 need be extremely wary of using this tag, and verifiers 338 might wish to ignore the tag or remove text that appears 339 after the specified content length. 341 NOTE: The value of the "l=" tag is constrained to 76 decimal 342 digits. This constraint is not intended to predict the size 343 of future data or to require implementations to use an 344 integer representation large enough to represent the maximum 345 possible value, but is intended to remind the implementer to 346 check the length of this and all other tags during 347 verification and to test for integer overflow when decoding 348 the value. Implementers might need to limit the actual 349 value expressed to a value smaller than 10^76, for example, 350 to allow a message to fit within the available storage 351 space. 353 z= Copied Header fields (DOSETA-quoted-printable, but see 354 description; OPTIONAL, default is null). A vertical-bar- 355 separated list of selected Header fields present when the 356 message was signed, including both the field name and value. 357 It is not required to include all Header fields present at the 358 time of signing. This field need not contain the same Header 359 fields listed in the "h=" tag. The Header field text itself 360 MUST encode the vertical bar ("|", %x7C) character. That is, 361 vertical bars in the "z=" text are meta-characters, and any 362 actual vertical bar characters in a copied header field MUST be 363 encoded. Note that all whitespace MUST be encoded, including 364 whitespace between the colon and the header field value. After 365 encoding, FWS MAY be added at arbitrary locations in order to 366 avoid excessively long lines; such whitespace is NOT part of 367 the value of the header field, and MUST be removed before 368 decoding. 370 The Header fields referenced by the "h=" tag refer to the 371 fields in the [RFC5322] Header, not to any copied fields in the 372 "z=" tag. Copied header field values are for diagnostic use. 374 Header fields with characters requiring conversion (perhaps 375 from legacy MTAs that are not [RFC5322] compliant) SHOULD be 376 converted as described in MIME Part Three [RFC2047]. 378 ABNF: 380 sig-z-tag = %x7A [FWS] "=" [FWS] 381 sig-z-tag-copy 382 *( "|" [FWS] sig-z-tag-copy ) 383 sig-z-tag-copy = hdr-name [FWS] ":" 384 qp-hdr-value 386 EXAMPLE of a signature header field spread across multiple 387 continuation lines: 388 DKIM-Signature: v=1; a=rsa-sha256; d=example.net; 389 s=brisbane; c=simple; q=dns/txt; i=@eng.example.net; 390 t=1117574938; x=1118006938; 391 h=from:to:subject:date; 392 z=From:foo@eng.example.net|To:joe@example.com| 393 Subject:demo=20run| 394 Date:July=205,=202005=203:44:08=20PM=20-0700; 395 bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; 396 b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR 398 3.1.1. Content Length Limits {rfc4871bis-02 3.4.5} 400 A text length count MAY be specified to limit the signature 401 calculation to an initial prefix of an ASCII text data portion, 402 measured in octets. If the Content length count is not specified, 403 the entire Content is signed. 405 This capability is provided because it is very common for 406 intermediate data handling services to add trailers to text (for 407 example, instructions how to get off a mailing list). Until such 408 data is signed by the intermediate handler, the text length count can 409 be a useful tool for the verifier since it can, as a matter of 410 policy, accept messages having valid signatures that do not cover the 411 additional data. 413 NOTE: Using text length limits enables an attack in which an 414 attacker modifies a message to include content that solely 415 benefits the attacker. It is possible for the appended content to 416 completely replace the original content in the end recipient's 417 eyes and to defeat duplicate message detection algorithms. To 418 avoid this attack, signers need to be wary of using this tag, and 419 verifiers might wish to ignore the tag or remove text that appears 420 after the specified content length, perhaps based on other 421 criteria. 423 The text length count allows the signer of text to permit data to be 424 appended to the end of the text of a signed message. The text length 425 count MUST be calculated following the canonicalization algorithm; 426 for example, any whitespace ignored by a canonicalization algorithm 427 is not included as part of the Content length count. Signers of MIME 428 messages that include a Content length count SHOULD be sure that the 429 length extends to the closing MIME boundary string. 431 NOTE: A creator wishing to ensure that the only acceptable 432 modifications are to add to a MIME postlude would use a text 433 length count encompassing the entire final MIME boundary string, 434 including the final "--CRLF". A signer wishing to allow 435 additional MIME parts but not modification of existing parts would 436 use a Content length count extending through the final MIME 437 boundary string, omitting the final "--CRLF". Note that this only 438 works for some MIME types, such as, multipart/mixed but not 439 multipart/signed. 441 A text length count of zero means that the text is completely 442 unsigned. 444 Creators wishing to ensure that no modification of any sort can occur 445 will specify the "simple" canonicalization algorithm for all data 446 portions and will and omit the text length counts. 448 3.1.2. Recommended Signature Content {rfc4871bis-02 5.5} 450 In order to maximize compatibility with a variety of verifiers, it is 451 recommended that signers follow the practices outlined in this 452 section when signing a message. However, these are generic 453 recommendations applying to the general case; specific senders might 454 wish to modify these guidelines as required by their unique 455 situations. Verifiers MUST be capable of verifying signatures even 456 if one or more of the recommended Header fields is not signed (with 457 the exception of From:, which MUST always be signed) or if one or 458 more of the dis-recommended Header fields is signed. Note that 459 verifiers do have the option of ignoring signatures that do not cover 460 a sufficient portion of the header or Content, just as they might 461 ignore signatures from an identity they do not trust. 463 The following Header fields SHOULD be included in the signature, if 464 they are present in the message being signed: 466 o From (REQUIRED in all signatures) 468 o Sender, Reply-To 470 o Subject 472 o Date, Message-ID 474 o To, Cc 476 o MIME-Version 477 o Content-Type, Content-Transfer-Encoding, Content-ID, Content- 478 Description 480 o Resent-Date, Resent-From, Resent-Sender, Resent-To, Resent-Cc, 481 Resent-Message-ID 483 o In-Reply-To, References 485 o List-Id, List-Help, List-Unsubscribe, List-Subscribe, List-Post, 486 List-Owner, List-Archive 488 The following Header fields SHOULD NOT be included in the signature: 490 o Return-Path 492 o Received 494 o Comments, Keywords 496 o Bcc, Resent-Bcc 498 o DOSETA-Signature 500 Optional Header fields (those not mentioned above) normally SHOULD 501 NOT be included in the signature, because of the potential for 502 additional Header fields of the same name to be legitimately added or 503 reordered prior to verification. There are likely to be legitimate 504 exceptions to this rule, because of the wide variety of application- 505 specific Header fields that might be applied to a message, some of 506 which are unlikely to be duplicated, modified, or reordered. 508 Signers SHOULD choose canonicalization algorithms based on the types 509 of data they process and their aversion to risk. For example, 510 e-commerce sites sending primarily purchase receipts, which are not 511 expected to be processed by intermediaries such as mailing lists or 512 other software likely to modify data, will generally prefer "simple" 513 canonicalization. Sites sending primarily person-to-person data will 514 likely prefer to be more resilient to modification during transport 515 by using "relaxed" canonicalization. 517 Signers SHOULD NOT use "l=" unless they intend to accommodate 518 intermediate data processors that append text to a message. For 519 example, many mailing list processors append "unsubscribe" 520 information to message bodies. If signers use "l=", they SHOULD 521 include the entire Content existing at the time of signing in 522 computing the count. In particular, signers SHOULD NOT specify a 523 Content length of 0 since this might be interpreted as a meaningless 524 signature by some verifiers. 526 3.1.3. Signature Verification {rfc4871bis-02 6.1.3, subset} 528 A Content length specified in the "l=" tag of the signature limits 529 the number of bytes of the Content passed to the verification 530 algorithm. All data beyond that limit is not validated by DOSETA. 531 Hence, verifiers might treat a message that contains bytes beyond the 532 indicated Content length with suspicion, such as by truncating the 533 message at the indicated Content length, declaring the signature 534 invalid (for example, by returning PERMFAIL (unsigned content)), or 535 conveying the partial verification to the policy module. 537 NOTE: Verifiers that truncate the Content at the indicated Content 538 length might pass on a malformed MIME message if the signer used 539 the "N-4" trick (omitting the final "--CRLF") described in the 540 informative note in Section 3.1.1. Such verifiers might wish to 541 check for this case and include a trailing "--CRLF" to avoid 542 breaking the MIME structure. A simple way to achieve this might 543 be to append "--CRLF" to any "multipart" message with a Content 544 length; if the MIME structure is already correctly formed, this 545 will appear in the postlude and will not be displayed to the end 546 user. 548 3.2. Relationship between SDID and AUID {rfc4871bis-02 3.9} 550 DOSETA's primary task is to communicate from the Signer to a 551 recipient-side Identity Assessor a single Signing Domain Identifier 552 (SDID) that refers to a responsible identity. DOSETA MAY optionally 553 provide a single responsible Agent or User Identifier (AUID). 555 Hence, DOSETA's mandatory output to a receive-side Identity Assessor 556 is a single domain name. Within the scope of its use as DOSETA 557 output, the name has only basic domain name semantics; any possible 558 owner-specific semantics are outside the scope of DOSETA. That is, 559 within its role as a DOSETA identifier, additional semantics cannot 560 be assumed by an Identity Assessor. 562 Upon successfully verifying the signature, a receive-side DOSETA 563 verifier MUST communicate the Signing Domain Identifier (d=) to a 564 consuming Identity Assessor module and MAY communicate the Agent or 565 User Identifier (i=) if present. 567 To the extent that a receiver attempts to intuit any structured 568 semantics for either of the identifiers, this is a heuristic function 569 that is outside the scope of DOSETA's specification and semantics. 570 Hence, it is relegated to a higher-level service, such as a delivery 571 handling filter that integrates a variety of inputs and performs 572 heuristic analysis of them. 574 This document does not require the value of the SDID or AUID to match 575 an identifier in any other message header field. Such a requirement 576 is, instead, an assessor policy issue. The purpose of such a linkage 577 could be to authenticate the value in that other header field. This, 578 in turn, is the basis for applying a trust assessment based on the 579 identifier value. Trust is a broad and complex topic and trust 580 mechanisms are subject to highly creative attacks. The real-world 581 efficacy of any but the most basic bindings between the SDID or AUID 582 and other identities is not well established, nor is its 583 vulnerability to subversion by an attacker. Hence, reliance on the 584 use of such bindings SHOULD be strictly limited. In particular, it 585 is not at all clear to what extent a typical end-user recipient can 586 rely on any assurances that might be made by successful use of the 587 SDID or AUID. 589 3.3. Stored Key Data {rfc4871bis-02 3.6.1, subset} 591 This section defines additions to the DOSETA Library, concerning 592 stored key data. 594 g= Granularity of the key (plain-text; OPTIONAL, default is 595 "*"). This value MUST match the Local-part of the "i=" tag of 596 the DKIM- Signature header field (or its default value of the 597 empty string if "i=" is not specified), with a single, optional 598 "*" character matching a sequence of zero or more arbitrary 599 characters ("wildcarding"). An email with a signing address 600 that does not match the value of this tag constitutes a failed 601 verification. The intent of this tag is to constrain which 602 signing address can legitimately use this selector, for 603 example, when delegating a key to a third party that should 604 only be used for special purposes. Wildcarding allows matching 605 for addresses such as "user+*" or "*-offer". An empty "g=" 606 value never matches any addresses. 608 ABNF: 609 key-g-tag = %x67 [FWS] "=" [FWS] key-g-tag-lpart 610 key-g-tag-lpart = [dot-atom-text] 611 ["*" [dot-atom-text] ] 613 h= Acceptable hash algorithms (plain-text; OPTIONAL, defaults 614 to allowing all algorithms). A colon-separated list of hash 615 algorithms that might be used. Signers and Verifiers MUST 616 support the "sha256" hash algorithm. Verifiers MUST also 617 support the "sha1" hash algorithm. Unrecognized hash 618 algorithms MUST be ignored. 620 ABNF: 622 key-h-tag = %x68 [FWS] "=" [FWS] 623 key-h-tag-alg 624 0*( [FWS] ":" [FWS] 625 key-h-tag-alg ) 626 key-h-tag-alg = "sha1" / "sha256" / 627 x-key-h-tag-alg 628 x-key-h-tag-alg = hyphenated-word 629 ; for future extension 631 s= Service Type (plain-text; OPTIONAL; default is "*"). A 632 colon-separated list of service types to which this record 633 applies. Verifiers for a given service type MUST ignore this 634 record if the appropriate type is not listed. Unrecognized 635 service types MUST be ignored. Currently defined service types 636 are as follows: 638 * matches all service types 640 email electronic mail (not necessarily limited to SMTP) 642 This tag is intended to constrain the use of keys for other 643 purposes, if use of DOSETA is defined by other services in the 644 future. 646 ABNF: 648 key-s-tag = %x73 [FWS] "=" [FWS] 649 key-s-tag-type 650 0*( [FWS] ":" [FWS] 651 key-s-tag-type ) 652 key-s-tag-type = "email" / "*" / 653 x-key-s-tag-type 654 x-key-s-tag-type = hyphenated-word 655 ; for future extension 657 t= Flags, represented as a colon-separated list of names 658 (plain-text; OPTIONAL, default is no flags set). Unrecognized 659 flags MUST be ignored. The defined flags are as follows: 661 y This domain is testing DOSETA. Verifiers MUST NOT treat 662 data from signers in testing mode differently from unsigned 663 data, even if the signature fails to verify. Verifiers MAY 664 wish to track testing mode results to assist the signer. 666 s Any DOSETA-Signature Header fields using the "i=" tag MUST 667 have the same domain value on the right-hand side of the "@" 668 in the "i=" tag and the value of the "d=" tag. That is, the 669 "i=" domain MUST NOT be a subdomain of "d=". Use of this 670 flag is RECOMMENDED unless subdomaining is required. 672 ABNF: 673 key-t-tag = %x74 [FWS] "=" [FWS] 674 key-t-tag-flag 675 0*( [FWS] ":" [FWS] 676 key-t-tag-flag ) 677 key-t-tag-flag = "y" / "s" / 678 x-key-t-tag-flag 679 x-key-t-tag-flag = hyphenated-word 680 ; for future extension 682 4. Considerations 684 4.1. Security Considerations {rfc4871bis-02 8, subset} 686 4.1.1. Misuse of Content Length Limits ("l=" Tag) 688 Content length limits (in the form of the "l=" tag) are subject to 689 several potential attacks. 691 4.1.1.1. Addition of New MIME Parts to Multipart/* 693 If the Content length limit does not cover a closing MIME multipart 694 section (including the trailing "--CRLF" portion), then it is 695 possible for an attacker to intercept a properly signed multipart 696 message and add a new Content part. Depending on the details of the 697 MIME type and the implementation of the Consumer, this could allow an 698 attacker to change the information displayed to an end user from an 699 apparently trusted source. 701 For example, if attackers can append information to a "text/html" 702 Content part, they might be able to exploit a bug in some MUAs that 703 continue to read after a "" marker, and thus display HTML text 704 on top of already displayed text. If a message has a "multipart/ 705 alternative" Content part, they might be able to add a new Content 706 part that is preferred by the displaying MUA. 708 4.1.1.2. Addition of new HTML content to existing content 710 Several receiving MUA implementations do not cease display after a 711 """" tag. In particular, this allows attacks involving 712 overlaying images on top of existing text. 714 EXAMPLE: Appending the following text to an existing, properly closed 715 message will in many MUAs result in inappropriate data being rendered 716 on top of existing, correct data: 717
718
721 4.2. IANA Considerations {rfc4871bis-02 7, subset} 723 DKIM uses registries now assigned to DOSETA [I-D.Doseta]. This 724 section specifies additions to the registries that were in the 725 original DKIM Signing specification. They are not part of the DOSETA 726 specification, but are now specific to DKIM. 728 4.2.1. DKIM-Signature Tag Specifications 730 These values are added to the registry that is now defined in 731 [I-D.Doseta]: 733 +------+------------------------------+ 734 | TYPE | REFERENCE | 735 +------+------------------------------+ 736 | i | (this document, Section 3.1) | 737 | l | (this document, Section 3.1) | 738 | z | (this document, Section 3.1) | 739 +------+------------------------------+ 741 Table 1: DKIM-Signature Tag Specification Registry Initial Values 743 4.2.2. _domainkey DNS TXT Record Tag Specifications 745 These values are added to the registry that is now defined in 746 [I-D.Doseta]: 748 +------+------------------------------+ 749 | TYPE | REFERENCE | 750 +------+------------------------------+ 751 | g | (this document, Section 3.3) | 752 | h | (this document, Section 3.3) | 753 | s | (this document, Section 3.3) | 754 | t | (this document, Section 3.3) | 755 +------+------------------------------+ 757 DKIT _domainkey DNS TXT Record Tag Specification Registry 758 Initial Values 760 4.2.3. DKIM Service Types Registry 762 The "s=" tag (specified in Section 3.3) provides for a 763 list of service types to which this selector might apply. 765 IANA has established the DKIM Service Types Registry for service 766 types. 768 The initial entries in the registry comprise: 770 +-------+--------------------------------------+ 771 | TYPE | REFERENCE | 772 +-------+--------------------------------------+ 773 | email | (this document, Section 3.3, "s=") | 774 | * | (this document, , Section 3.3, "s=") | 775 +-------+--------------------------------------+ 777 DKIM Service Types Registry Initial Values 779 4.2.4. DKIM Service Flags Registry 781 The "t=" tag (specified in Section 3.3) provides for a 782 list of flags to modify interpretation of the selector. 784 IANA has established the DKIM Selector Flags Registry for additional 785 flags. 787 The initial entries in the registry comprise: 789 +------+------------------------------------+ 790 | TYPE | REFERENCE | 791 +------+------------------------------------+ 792 | y | (this document, Section 3.3, "t=") | 793 | s | (this document, Section 3.3, "t=") | 794 +------+------------------------------------+ 795 DKIM Service Flags Registry Initial Values 797 4.2.5. DKIM-Signature Header Field 799 IANA has added DKIM-Signature to the "Permanent Message Header 800 Fields" registry (see [RFC3864]) for the "mail" protocol, using this 801 document as the reference. 803 5. References 805 5.1. Normative References 807 [I-D.Doseta] 808 Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., 809 "DomainKeys Security Tagging (DOSETA)", 810 I-D draft-ietf-DKIM-DOSETA, 2010. 812 [RFC1034] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", 813 RFC 1034, November 1987. 815 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 816 Part Three: Message Header Extensions for Non-ASCII 817 Content", RFC 2047, November 1996. 819 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 820 Requirement Levels", BCP 14, RFC 2119, March 1997. 822 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 823 Specifications: ABNF", RFC 4234, January 2008. 825 [RFC5322] Resnick, P., "Internet Message Format", RFC 5322, 826 October 2008. 828 [RFC5672] Crocker, D., Ed., "RFC 4871 DomainKeys Identified Mail 829 (DKIM) Signatures: Update", RFC 5672, August 2009. 831 [RFC5890] Klensin, J., "Internationalizing Domain Names in 832 Applications (IDNA): Definitions and Document Framework", 833 RFC 5890, August 2010. 835 5.2. Informative References 837 [RFC1847] Galvin, J., Murphy, S., Crocker, S., and N. Freed, 838 "Security Multiparts for MIME: Multipart/Signed and 839 Multipart/Encrypted", RFC 1847, October 1995. 841 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 842 Procedures for Message Header Fields", BCP 90, RFC 3864, 843 September 2004. 845 [RFC4870] Delany, M., "Domain-Based Email Authentication Using 846 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 847 May 2007. 849 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 850 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 851 Signatures", RFC 4871, May 2007. 853 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 854 "OpenPGP Message Format", RFC 4880, November 2007. 856 [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys 857 Identified Mail (DKIM) Service Overview", June 2009. 859 [RFC5863] Hansen, T., Siegel, H., Hallam-Baker, P., and D. Crocker, 860 "DomainKeys Identified Mail (DKIM): Development, 861 Deployment, and Operations", May 2010. 863 Appendix A. MUA Considerations {rfc4871bis-02 D} 865 When a DKIM signature is verified, the processing system sometimes 866 makes the result available to the recipient user's MUA. How to 867 present this information to the user in a way that helps them is a 868 matter of continuing human factors usability research. The tendency 869 is to have the MUA highlight the SDID, in an attempt to show the user 870 the identity that is claiming responsibility for the message. An MUA 871 might do this with visual cues such as graphics, or it might include 872 the address in an alternate view, or it might even rewrite the 873 original From address using the verified information. Some MUAs 874 might indicate which header fields were protected by the validated 875 DKIM signature. This could be done with a positive indication on the 876 signed header fields, with a negative indication on the unsigned 877 header fields, by visually hiding the unsigned header fields, or some 878 combination of these. If an MUA uses visual indications for signed 879 header fields, the MUA probably needs to be careful not to display 880 unsigned header fields in a way that might be construed by the end 881 user as having been signed. If the message has an l= tag whose value 882 does not extend to the end of the message, the MUA might also hide or 883 mark the portion of the message body that was not signed. 885 The aforementioned information is not intended to be exhaustive. The 886 MUA may choose to highlight, accentuate, hide, or otherwise display 887 any other information that may, in the opinion of the MUA author, be 888 deemed important to the end user. 890 Appendix B. End-to-End Scenario Example {rfc4871bis-02 A} 892 This section shows the complete flow of an email from submission to 893 final delivery, demonstrating how the various components fit 894 together. The key used in this example is shown in [I-D.Doseta], 895 "Creating a Public Key". 897 B.1. The User Composes an Email 899 From: Joe SixPack 900 To: Suzie Q 901 Subject: Is dinner ready? 902 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 903 Message-ID: <;20030712040037.46341.5F8J@football.example.com> 905 Hi. 907 We lost the game. Are you hungry yet? 909 Joe. 911 Figure 1: The User Composes an Email 913 B.2. The Email is Signed 914 This email is signed by the example.com outbound email server and now 915 looks like this: 916 DOSETA&nbhy;Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; 917 c=simple/simple; q=dns/txt; i=joe@football.example.com; 918 h=Received : From : To : Subject : Date : Message-ID; 919 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; 920 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 921 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut 922 KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 923 4bmp/YzhwvcubU4=; 924 Received: from client1.football.example.com [192.0.2.1] 925 by submitserver.example.com with SUBMISSION; 926 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 927 From: Joe SixPack 928 To: Suzie Q 929 Subject: Is dinner ready? 930 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 931 Message-ID: <20030712040037.46341.5F8J@football.example.com> 933 Hi. 935 We lost the game. Are you hungry yet? 937 Joe. 939 The Email is Signed 941 The signing email server requires access to the private key 942 associated with the "brisbane" selector to generate this signature. 944 B.3. The Email Signature is Verified 946 The signature is normally verified by an inbound SMTP server or 947 possibly the final delivery agent. However, intervening MTAs can 948 also perform this verification if they choose to do so. The 949 verification process uses the domain "example.com" extracted from the 950 "d=" tag and the selector "brisbane" from the "s=" tag in the 951 DOSETA-Signature header field to form the DNS DOSETA query for: 952 brisbane._domainkey.example.com 954 Signature verification starts with the physically last Received 955 header field, the From header field, and so forth, in the order 956 listed in the "h=" tag. Verification follows with a single CRLF 957 followed by the body (starting with "Hi."). The email is canonically 958 prepared for verifying with the "simple" method. The result of the 959 query and subsequent verification of the signature is stored (in this 960 example) in the X-Authentication-Results header field line. After 961 successful verification, the email looks like this: 963 X-Authentication-Results: shopping.example.net 964 header.from=joe@football.example.com; DOSETA=pass 965 Received: from mout23.football.example.com (192.168.1.1) 966 by shopping.example.net with SMTP; 967 Fri, 11 Jul 2003 21:01:59 -0700 (PDT) 968 DOSETA&nbhy;Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com; 969 c=simple/simple; q=dns/txt; i=joe@football.example.com; 970 h=Received : From : To : Subject : Date : Message-ID; 971 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; 972 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 973 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut 974 KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 975 4bmp/YzhwvcubU4=; 976 Received: from client1.football.example.com [192.0.2.1] 977 by submitserver.example.com with SUBMISSION; 978 Fri, 11 Jul 2003 21:01:54 -0700 (PDT) 979 From: Joe SixPack 980 To: Suzie Q 981 Subject: Is dinner ready? 982 Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT) 983 Message-ID: <20030712040037.46341.5F8J@football.example.com> 985 Hi. 987 We lost the game. Are you hungry yet? 989 Joe. 991 Successful verification 993 Appendix C. Types of Use {rfc4871bis-02 B} 995 DOSETA signing and validating can be used in different ways, for 996 different operational scenarios. This Appendix discusses some common 997 examples. 999 NOTE: Descriptions in this Appendix are for informational purposes 1000 only. They describe various ways that DOSETA can be used, given 1001 particular constraints and needs. In no case are these examples 1002 intended to be taken as providing explanation or guidance 1003 concerning DOSETA specification details, when creating an 1004 implementation. 1006 C.1. Alternate Submission Scenarios 1008 In the most simple scenario, a user's MUA, MSA, and Internet 1009 (boundary) MTA are all within the same administrative environment, 1010 using the same domain name. Therefore, all of the components 1011 involved in submission and initial transfer are related. However, it 1012 is common for two or more of the components to be under independent 1013 administrative control. This creates challenges for choosing and 1014 administering the domain name to use for signing, and for its 1015 relationship to common email identity Header fields. 1017 C.1.1. Delegated Business Functions 1019 Some organizations assign specific business functions to discrete 1020 groups, inside or outside the organization. The goal, then, is to 1021 authorize that group to sign some mail, but to constrain what 1022 signatures they can generate. DOSETA selectors (the "s=" signature 1023 tag) facilitate this kind of restricted authorization. Examples of 1024 these outsourced business functions are legitimate email marketing 1025 providers and corporate benefits providers. 1027 Here, the delegated group needs to be able to send messages that are 1028 signed, using the email domain of the client company. At the same 1029 time, the client often is reluctant to register a key for the 1030 provider that grants the ability to send messages for arbitrary 1031 addresses in the domain. 1033 There are multiple ways to administer these usage scenarios. In one 1034 case, the client organization provides all of the public query 1035 service (for example, DNS) administration, and in another it uses DNS 1036 delegation to enable all ongoing administration of the DOSETA key 1037 record by the delegated group. 1039 If the client organization retains responsibility for all of the DNS 1040 administration, the outsourcing company can generate a key pair, 1041 supplying the public key to the client company, which then registers 1042 it in the query service, using a unique selector. The client company 1043 retains control over the use of the delegated key because it retains 1044 the ability to revoke the key at any time. 1046 If the client wants the delegated group to do the DNS administration, 1047 it can have the domain name that is specified with the selector point 1048 to the provider's DNS server. The provider then creates and 1049 maintains all of the DKIM signature information for that selector. 1050 Hence, the client cannot provide constraints on the of 1051 addresses that get signed, but it can revoke the provider's signing 1052 rights by removing the DNS delegation record. 1054 C.1.2. PDAs and Similar Devices 1056 PDAs demonstrate the need for using multiple keys per domain. 1057 Suppose that John Doe wanted to be able to send messages using his 1058 corporate email address, jdoe@example.com, and his email device did 1059 not have the ability to make a Virtual Private Network (VPN) 1060 connection to the corporate network, either because the device is 1061 limited or because there are restrictions enforced by his Internet 1062 access provider. If the device was equipped with a private key 1063 registered for jdoe@example.com by the administrator of the 1064 example.com domain, and appropriate software to sign messages, John 1065 could sign the message on the device itself before transmission 1066 through the outgoing network of the access service provider. 1068 C.1.3. Roaming Users 1070 Roaming users often find themselves in circumstances where it is 1071 convenient or necessary to use an SMTP server other than their home 1072 server; examples are conferences and many hotels. In such 1073 circumstances, a signature that is added by the submission service 1074 will use an identity that is different from the user's home system. 1076 Ideally, roaming users would connect back to their home server using 1077 either a VPN or a SUBMISSION server running with SMTP AUTHentication 1078 on port 587. If the signing can be performed on the roaming user's 1079 laptop, then they can sign before submission, although the risk of 1080 further modification is high. If neither of these are possible, 1081 these roaming users will not be able to send mail signed using their 1082 own domain key. 1084 C.1.4. Independent (Kiosk) Message Submission 1086 Stand-alone services, such as walk-up kiosks and web-based 1087 information services, have no enduring email service relationship 1088 with the user, but users occasionally request that mail be sent on 1089 their behalf. For example, a website providing news often allows the 1090 reader to forward a copy of the article to a friend. This is 1091 typically done using the reader's own email address, to indicate who 1092 the author is. This is sometimes referred to as the "Evite problem", 1093 named after the website of the same name that allows a user to send 1094 invitations to friends. 1096 A common way this is handled is to continue to put the reader's email 1097 address in the From header field of the message, but put an address 1098 owned by the email posting site into the Sender header field. The 1099 posting site can then sign the message, using the domain that is in 1100 the Sender field. This provides useful information to the receiving 1101 email site, which is able to correlate the signing domain with the 1102 initial submission email role. 1104 Receiving sites often wish to provide their end users with 1105 information about mail that is mediated in this fashion. Although 1106 the real efficacy of different approaches is a subject for human 1107 factors usability research, one technique that is used is for the 1108 verifying system to rewrite the From header field, to indicate the 1109 address that was verified. For example: From: John Doe via 1110 news@news-site.com . (Note that such rewriting 1111 will break a signature, unless it is done after the verification pass 1112 is complete.) 1114 C.2. Alternate Delivery Scenarios 1116 Email is often received at a mailbox that has an address different 1117 from the one used during initial submission. In these cases, an 1118 intermediary mechanism operates at the address originally used and it 1119 then passes the message on to the final destination. This mediation 1120 process presents some challenges for DKIM signatures. 1122 C.2.1. Affinity Addresses 1124 "Affinity addresses" allow a user to have an email address that 1125 remains stable, even as the user moves among different email 1126 providers. They are typically associated with college alumni 1127 associations, professional organizations, and recreational 1128 organizations with which they expect to have a long-term 1129 relationship. These domains usually provide forwarding of incoming 1130 email, and they often have an associated Web application that 1131 authenticates the user and allows the forwarding address to be 1132 changed. However, these services usually depend on users sending 1133 outgoing messages through their own service providers' MTAs. Hence, 1134 mail that is signed with the domain of the affinity address is not 1135 signed by an entity that is administered by the organization owning 1136 that domain. 1138 With DOSETA, affinity domains could use the Web application to allow 1139 users to register per-user keys to be used to sign messages on behalf 1140 of their affinity address. The user would take away the secret half 1141 of the key pair for signing, and the affinity domain would publish 1142 the public half in DNS for access by verifiers. 1144 This is another application that takes advantage of user-level 1145 keying, and domains used for affinity addresses would typically have 1146 a very large number of user-level keys. Alternatively, the affinity 1147 domain could handle outgoing mail, operating a mail submission agent 1148 that authenticates users before accepting and signing messages for 1149 them. This is of course dependent on the user's service provider not 1150 blocking the relevant TCP ports used for mail submission. 1152 C.2.2. Simple Address Aliasing (.forward) 1154 In some cases a recipient is allowed to configure an email address to 1155 cause automatic redirection of email messages from the original 1156 address to another, such as through the use of a Unix .forward file. 1157 In this case, messages are typically redirected by the mail handling 1158 service of the recipient's domain, without modification, except for 1159 the addition of a Received header field to the message and a change 1160 in the envelope recipient address. In this case, the recipient at 1161 the final address' mailbox is likely to be able to verify the 1162 original signature since the signed content has not changed, and 1163 DOSETA is able to validate the message signature. 1165 C.2.3. Mailing Lists and Re-Posters 1167 There is a wide range of behaviors in services that take delivery of 1168 a message and then resubmit it. A primary example is with mailing 1169 lists (collectively called "forwarders" below), ranging from those 1170 that make no modification to the message itself, other than to add a 1171 Received header field and change the envelope information, to those 1172 that add Header fields, change the Subject header field, add content 1173 to the body (typically at the end), or reformat the body in some 1174 manner. The simple ones produce messages that are quite similar to 1175 the automated alias services. More elaborate systems essentially 1176 create a new message. 1178 A Forwarder that does not modify the body or signed Header fields of 1179 a message is likely to maintain the validity of the existing 1180 signature. It also could choose to add its own signature to the 1181 message. 1183 Forwarders which modify a message in a way that could make an 1184 existing signature invalid are particularly good candidates for 1185 adding their own signatures (for example, 1186 mailing-list-name@example.net). Since (re-)signing is taking 1187 responsibility for the data, these signing forwarders are likely to 1188 be selective, and forward or re-sign a message only if it is received 1189 with a valid signature or if they have some other basis for knowing 1190 that the message is not spoofed. 1192 A common practice among systems that are primarily redistributors of 1193 mail is to add a Sender header field to the message, to identify the 1194 address being used to sign the message. This practice will remove 1195 any preexisting Sender header field as required by [RFC5322]. The 1196 forwarder applies a new DOSETA-Signature header field with the 1197 signature, public key, and related information of the forwarder. 1199 Appendix D. Acknowledgements 1201 The previous IETF version of DKIM [RFC4871] was edited by: Eric 1202 Allman, Jon Callas, Mark Delany, Miles Libbey, Jim Fenton and Michael 1203 Thomas. 1205 That specification was the result of an extended, collaborative 1206 effort, including participation by: Russ Allbery, Edwin Aoki, Claus 1207 Assmann, Steve Atkins, Rob Austein, Fred Baker, Mark Baugher, Steve 1208 Bellovin, Nathaniel Borenstein, Dave Crocker, Michael Cudahy, Dennis 1209 Dayman, Jutta Degener, Frank Ellermann, Patrik Faeltstroem, Mark 1210 Fanto, Stephen Farrell, Duncan Findlay, Elliot Gillum, Olafur 1211 Gu[eth]mundsson, Phillip Hallam-Baker, Tony Hansen, Sam Hartman, 1212 Arvel Hathcock, Amir Herzberg, Paul Hoffman, Russ Housley, Craig 1213 Hughes, Cullen Jennings, Don Johnsen, Harry Katz, Murray S. 1214 Kucherawy, Barry Leiba, John Levine, Charles Lindsey, Simon 1215 Longsdale, David Margrave, Justin Mason, David Mayne, Thierry Moreau, 1216 Steve Murphy, Russell Nelson, Dave Oran, Doug Otis, Shamim Pirzada, 1217 Juan Altmayer Pizzorno, Sanjay Pol, Blake Ramsdell, Christian Renaud, 1218 Scott Renfro, Neil Rerup, Eric Rescorla, Dave Rossetti, Hector 1219 Santos, Jim Schaad, the Spamhaus.org team, Malte S. Stretz, Robert 1220 Sanders, Rand Wacker, Sam Weiler, and Dan Wing. 1222 The earlier DomainKeys was a primary source from which DKIM was 1223 derived. Further information about DomainKeys is at [RFC4870]. 1225 Authors' Addresses 1227 D. Crocker (editor) 1228 Brandenburg InternetWorking 1229 675 Spruce Dr. 1230 Sunnyvale 1231 USA 1233 Phone: +1.408.246.8253 1234 Email: dcrocker@bbiw.net 1235 URI: http://bbiw.net 1237 M. Kucherawy (editor) 1238 Cloudmark 1239 128 King St., 2nd Floor 1240 San Francisco, CA 94107 1241 USA 1243 Email: msk@cloudmark.com