idnits 2.17.1 draft-hoffman-dac-vbr-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.ii 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 : ---------------------------------------------------------------------------- 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (February 25, 2009) is 5539 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 610, but not defined -- Obsolete informational reference (is this intentional?): RFC 4408 (Obsoleted by RFC 7208) -- 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: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Hoffman 3 Internet-Draft J. Levine 4 Intended status: Standards Track Domain Assurance Council 5 Expires: August 29, 2009 A. Hathcock 6 Alt-N Technologies 7 February 25, 2009 9 Vouch By Reference 10 draft-hoffman-dac-vbr-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 August 29, 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 document describes the Vouch By Reference (VBR) protocol. VBR 59 is a protocol for adding third-party certification to email. It 60 permits independent third parties to certify the owner of a domain 61 name that is associated with received mail. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Use of the VBR-Info Header Field . . . . . . . . . . . . . . . 4 68 3. Validation Process . . . . . . . . . . . . . . . . . . . . . . 4 69 4. The VBR-Info Header Field . . . . . . . . . . . . . . . . . . 5 70 4.1. Syntax of VBR-Info Header Fields . . . . . . . . . . . . . 5 71 5. DNS Query . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Types of Message Content . . . . . . . . . . . . . . . . . . . 7 73 6.1. All . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 6.2. List . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6.3. Transaction . . . . . . . . . . . . . . . . . . . . . . . 8 76 7. Obtaining a Useful Domain Name . . . . . . . . . . . . . . . . 8 77 7.1. DKIM . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7.2. DomainKeys . . . . . . . . . . . . . . . . . . . . . . . . 9 79 7.3. SPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 7.4. Sender ID . . . . . . . . . . . . . . . . . . . . . . . . 9 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 86 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 87 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 12 88 B.1. Changes from 00 to 01 . . . . . . . . . . . . . . . . . . 12 89 B.2. Changes from 01 to 02 . . . . . . . . . . . . . . . . . . 12 90 B.3. Changes from 02 to 03 . . . . . . . . . . . . . . . . . . 12 91 B.4. Changes from 03 to 04 . . . . . . . . . . . . . . . . . . 12 92 B.5. Changes from 04 to 05 . . . . . . . . . . . . . . . . . . 13 93 B.6. Changes from 05 to 06 . . . . . . . . . . . . . . . . . . 13 94 B.7. Changes from 06 to 07 . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 97 1. Introduction 99 Vouch By Reference, or VBR, is a protocol for adding third-party 100 certification to email. Specifically, VBR permits independent third 101 parties to certify the owner of a domain name that is associated with 102 received mail. VBR may be performed anywhere along the email transit 103 path, by any capable receiving module, either within the handling 104 service or by end-user software. 106 VBR accomplishes this with a two-part protocol: 108 o In the first part, a sender affixes VBR information to email 109 messages. The VBR information says which domain certification 110 services the sender believes will vouch for email traffic 111 associated with that sender. 112 o In the second part, the receiver queries one or more certification 113 services to obtain information about the identity that has been 114 associated with a received message. This latter protocol uses the 115 DNS to distribute the certification information. 117 A sender provides certification attestations through the use of a new 118 RFC 5322 [RFC5322] mail header field, "VBR-Info:". This header field 119 contains the names of services that the sender claims will vouch for 120 it, and the particular type of content of the message. A queried, 121 third-party, DNS-based certification service can respond with a list 122 of the types of message content it will vouch for, such as 123 "transactional mail from somebank.example" and/or "all mail from 124 anotherbank.example". 126 A prerequisite for successful VBR operation is validation of the 127 identity associated with the message. VBR is based on the use of 128 domain names as identifiers, and permits multiple methods of 129 obtaining and validating domain names. The validation methods are 130 described in the "Obtaining a useful domain name" section below. 132 The sender performs two steps: 134 1. Adds a VBR-Info header field to its message 135 2. Protects the message, as appropriate 137 If a recipient uses the results of vouching to adjust spam scores on 138 incoming email, that recipient is placing a great deal of operational 139 trust and power in the vouching service. Therefore, recipients need 140 to select such services with care. Further, such recipients may want 141 to select more than one vouching service in order to avoid a single 142 point of failure for setting spam scores. 144 1.1. Definitions 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 2. Use of the VBR-Info Header Field 152 A sender uses VBR to indicate which domain certification services the 153 sender believes will vouch for a particular piece of mail. The 154 certification service uses VBR to state for which signatures it will 155 vouch. This protocol uses the DNS to distribute the certification 156 information. 158 A message may have multiple VBR-Info header fields. This means that, 159 in the terminology of RFC 5322, VBR-Info is a "trace header field" 160 and SHOULD be added at the top of the header fields. 162 The content of the VBR-Info header field is a list of three elements: 164 o The accountable domain 165 o The type of content in the message 166 o A list of domain names of services that the sender expects to 167 vouch for the sender for that kind of content 169 The accountable domain is given as md= followed by a domain name. 170 The content type is given as mc= followed by a string; the defined 171 values of that string are found below. The list of services is given 172 as mv= followed by a colon-separated list of domain names. 174 The formal syntax of the header field is defined in section 4. 176 3. Validation Process 178 A message receiver uses VBR to determine certification status by 179 following these steps: 181 1. Extracts the domain to certify and the type of message content 182 2. Verifies legitimate use of that domain using one or more 183 authentication mechanisms as described herein 184 3. Obtains the name of a vouching service that it trusts, either 185 from among the set supplied by the sender or from a locally- 186 defined set of preferred vouching services 187 4. Queries the vouching service to determine whether the vouching 188 service actually vouches for that type of content for that 189 domain. 191 4. The VBR-Info Header Field 193 The VBR-Info header field has the following format: 195 VBR-Info: md=; mc=; mv=; 197 where is the domain for which vouching is offered, is the content type of the message, and is a 199 list of domain names of certification providers that the sender 200 asserts will vouch for this particular message. The structure of the 201 is one or more domain names, with a colon (":") 202 between each. The elements in the domain, type-string, and 203 certifier-list must not have any white space in them. 205 For example, assume that the signer has two companies that are 206 willing to vouch for its transactional notices: certifier-a.example 207 and certifier-b.example. The signer would add the following to the 208 header of its outgoing message. 210 VBR-Info: md=somebank.example; mc=transaction; 211 mv=certifier-a.example:certifier-b.example; 213 All three header parameters in the VBR-Info header are mandatory. In 214 particular, there is no default for the md= domain. 216 Upper and lower case characters in a VBR-Info header field are 217 equivalent, although conventionally the contents are all in lower 218 case. For upward compatibility, verifiers MUST accept the fields in 219 any order and SHOULD ignore any fields other than the three defined 220 here. 222 If a message has more than one VBR-Info header field, verifiers 223 SHOULD check each in turn or in parallel until either a satisfactory 224 certifier is found or all the header fields have been checked. All 225 of the VBR-Info header fields in a single message MUST have identical 226 mc= values. 228 4.1. Syntax of VBR-Info Header Fields 230 In the ABNF below, the ALPHA and DIGIT tokens are imported from 231 [RFC5234], and the FWS and domain-name tokens are imported from 232 [RFC4871]. 234 vbr-info-header = "VBR-Info:" 1*([FWS] element [FWS] ";") 235 element = md-element / mc-element / mv-element 237 md-element = "md=" [FWS] domain-name 239 mc-element = "mc=" [FWS] type-string 240 type-string = "all" / "list" / "transaction" 242 mv-element = "mv=" [FWS] certifier-list 243 certifier-list = domain-name *(":" domain-name) 245 5. DNS Query 247 When a recipient wants to check whether a certification claim is 248 valid, it compares the list in the message to the list of services it 249 trusts. For each service that is on the intersection of the two 250 lists, it marshals a domain name to look up that consists of the 251 following DNS labels (from left to right): 253 o the domain name which asserts it can be certified 254 o _vouch (a string literal) 255 o the host name of the vouching service 257 This domain name is queried for a DNS TXT record. The recipient 258 looks up the domain name in the DNS in the exact same manner it looks 259 up all other domain names. 261 For example, if a message signed by somebank.example contained the 262 VBR-Info header field above, the receiver might look up either or 263 both of the following names, depending on which vouching service it 264 trusts: 266 somebank.example._vouch.certifier-b.example 267 somebank.example._vouch.certifier-a.example 269 If the DNS TXT record exists, it contains a space-delimited list of 270 all the types that the service certifies, given as lowercase ASCII. 271 For example, the contents of the TXT record might be: 273 transaction list 275 In the example above, the receiver checks whether or not either 276 certifier vouches for "transaction" mail. That would be indicated by 277 either of the following types: "all" or "transaction" ("all" 278 indicates that the certifier vouches for all message types sent by 279 the domain in question). If either of those types appear in either 280 TXT record, the certifier has vouched for the validity of the 281 message. Of course, the recipient needs to ignore services that it 282 does not trust; otherwise, a bad actor could just add an authority 283 that it has set up so that it can vouch for itself. 285 The name for the label _vouch was chosen because any domain name that 286 includes it as one of its labels cannot be a valid host name. There 287 will never be any accidental overlap with a valid host name. 288 Further, it is safe to create a rule that says that a TXT DNS record 289 that comes from a domain name that includes a _vouch label will 290 always have the structure defined in this document. 292 If the RDATA in the TXT record contains multiple character-strings 293 (as defined in section 3.3 of [RFC1035]), the code handling that 294 reply from DNS MUST assemble all of these marshalled text blocks into 295 a single one before any syntactical verification takes place. 297 Verifiers MUST then check that the TXT record consists of strings of 298 lowercase letters separated by spaces, and discard any records not in 299 that format. This defends against misconfigured records and 300 irrelevant records synthesized from DNS wildcards. 302 The VBR record MUST have only one TXT record. 304 This query method relies on the considerable advantages of existing 305 DNS efficiencies, reliability and experience. The lookup is very 306 efficient, and certifiers can add and delete client records as 307 quickly as they want. The lookup also leverages the DNS's negative 308 caching ([RFC2308]). 310 6. Types of Message Content 312 This section describes the types of content for which a certifier can 313 vouch. While the rest of the VBR specification is mostly technical 314 and precise, describing the types of contents in mail messages is 315 inherently open to interpretation. Thus, this section makes 316 distinctions as specifically as possible, but the reader needs to 317 understand that these semantic definitions can be interpreted in very 318 different ways by different people. 320 Note that the value in the mc= element is self-asserted. The purpose 321 of this element is for auditing. There will likely be cases where a 322 certifier will vouch for one type of a sender's mail (such as 323 transactional mail) but not another type (such as advertising). A 324 sender who cannot get anyone to certify its advertising mail, but has 325 a certifier for its transactional mail, might be tempted to cheat and 326 mislabel it as transactional. The mc= element creates an the audit 327 trail to help their certifiers catch such cheating and allow the 328 removal of the certification for the transactional mail. 330 Three types of content are defined. 332 6.1. All 334 "all" means all mail from the sender. 336 6.2. List 338 "list" is the category for email sent to multiple recipients where 339 each piece of mail is identical or is very similar to the others. 341 6.3. Transaction 343 "transaction" is the category for transactional messages. This is a 344 response to a specific action of the user, or a notice about an event 345 in the user's account at the sender. 347 7. Obtaining a Useful Domain Name 349 VBR relies on having a domain name that specifies a party that is 350 accountable for the message. This requires obtaining the domain name 351 and possessing a strong basis for believing that the use of the 352 domain name is valid, that is, that it has not been spoofed. 354 There are different ways to achieve this and this section discusses 355 the allowed mechanisms. Senders SHOULD use DKIM (and MAY use 356 DomainKeys, SPF, or SenderID) to give an accountable identity for the 357 sender. 359 7.1. DKIM 361 DomainKeys Identified Mail (DKIM), [RFC4871], defines an accountable 362 identity by associating a domain name with the message. It provides 363 assurance that the association is valid through a public-key-based 364 authentication mechanism. 366 o When DKIM is the validation mechanism, VBR's md= MUST match the 367 domain name taken from one of the DKIM-Signature header fields. 368 If the DKIM signature contains an i= field, the domain name from 369 that field is used; otherwise, the domain name from the DKIM 370 signature d= field is used. 371 o The VBR-Info header field SHOULD be included in the set of header 372 fields protected by DKIM to prevent a malicious party from 373 changing the contents of the VBR-Info header field or adding bogus 374 VBR-Info header fields. 376 o The VBR-Info header field SHOULD be added in the header 377 immediately below the corresponding DKIM-Signature header field. 379 If the DKIM signature validates, the domain name taken from that 380 signature is valid for use with VBR. 382 7.2. DomainKeys 384 DomainKeys (DK), [RFC4870]. defines an accountable identity by 385 associating a domain name with the message in the d= tag of the 386 DomainKey-Signature header field. It provides assurance that the 387 association is valid through a public-key-based authentication 388 mechanism. 390 o When DomainKeys is the validation mechanism, VBR's md= MUST be the 391 same value as the domain name found in the DomainKey-Signature d= 392 parameter. 393 o The VBR-Info header field SHOULD be included in the set of header 394 fields protected by DK to prevent a malicious party from changing 395 the contents of the VBR-Info header field or adding bogus VBR-Info 396 header fields. 397 o The VBR-Info header field SHOULD be added immediately below the 398 corresponding DomainKey-Signature header field. 400 If the DomainKeys signature validates, the domain in the d= tag is 401 valid for use with VBR. 403 7.3. SPF 405 Sender Policy Framework (SPF), [RFC4408], defines an accountable 406 identity by using an existing message address and querying the DNS to 407 discover whether it is valid for SPF use. 409 When SPF is the validation mechanism, VBR's md= MUST be the same 410 value as the domain name in the address that is the 411 first parameter to the SMTP MAIL command. 413 A domain is valid for use with VBR only when the SPF process produces 414 a "pass" result. 416 7.4. Sender ID 418 Sender ID, [RFC4406], defines an accountable identity by using an 419 existing message address known as the Purported Responsible Address 420 [RFC4407] and querying the DNS to discover whether it is valid for 421 Sender ID use. 423 When Sender ID is the validation mechanism, VBR's md= MUST be the 424 same value as the domain name in the Purported Responsible Address in 425 the message. 427 A domain is valid for use with VBR only when the Sender ID process 428 produces a "pass" result. 430 8. Security Considerations 432 VBR is used to allow users to trust independent third parties to 433 certify the owner of a domain name that is associated with received 434 mail. The party validating the mail might use that trust 435 relationship to perform actions that affect the security of their 436 system. 438 The receiver of a message with a VBR-Info header field MUST ignore 439 certifiers that it does not trust; otherwise, a bad actor could just 440 add an authority that it has set up so that it can vouch for itself. 442 Implementations SHOULD limit the number of VBR-Info header fields 443 they process in a single message in order to protect themselves from 444 a make-work or denial-of-service attack. 446 9. IANA Considerations 448 IANA is requested to register the VBR-Info header field in the 449 Message Header Fields Registry ([RFC3864]) as follows: 451 Header field name: VBR-Info 453 Applicable protocol: mail 455 Status: standard 457 Author/Change controller: IETF 459 Specification document(s): (Note to RFC Editor: the RFC number of 460 this document if approved) 462 Related information: none 464 10. References 465 10.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 471 October 2008. 473 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 474 Specifications: ABNF", STD 68, RFC 5234, January 2008. 476 10.2. Informative References 478 [RFC1035] Mockapetris, P., "Domain names - implementation and 479 specification", STD 13, RFC 1035, November 1987. 481 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS 482 NCACHE)", RFC 2308, March 1998. 484 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 485 Procedures for Message Header Fields", BCP 90, RFC 3864, 486 September 2004. 488 [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", 489 RFC 4406, April 2006. 491 [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail 492 Messages", RFC 4407, April 2006. 494 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) 495 for Authorizing Use of Domains in E-Mail, Version 1", 496 RFC 4408, April 2006. 498 [RFC4870] Delany, M., "Domain-Based Email Authentication Using 499 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, 500 May 2007. 502 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, 503 J., and M. Thomas, "DomainKeys Identified Mail (DKIM) 504 Signatures", RFC 4871, May 2007. 506 Appendix A. Acknowledgements 508 Many members of the Domain Assurance Council contributed to the 509 design of the protocol and the wording of this document. In 510 addition, constructive suggestions were received from Jim Fenton and 511 Murray Kucherawy. 513 Appendix B. Change Log 515 To be removed at time of publication 517 B.1. Changes from 00 to 01 519 Added a reference to negative DNS caching from RFC 2308. 521 Added a paragraph explaining that the mc= element is self-asserted 522 and why that is so. 524 Explained why the VBR-Info header should be signed in DKIM and DK. 526 When using DKIM, changed the rule for domain name matching to: If the 527 i= field is given, the domain name from that field is used; 528 otherwise, the value of the d= field is used. 530 Added a security consideration about limiting the number of VBR-Info 531 headers a system should process. 533 B.2. Changes from 01 to 02 535 Updated references to DK and DKIM for RFCs. 537 B.3. Changes from 02 to 03 539 Minor editorial changes. 541 Added the intended status. 543 B.4. Changes from 03 to 04 545 Changed the examples to use ".example" instead of ".com". 547 Updated references to RFC 2822 to RFC 5322. 549 Added reference to RFC 2119 and capitalized where appropriate. 551 Removed an incorrect comment on intended status. 553 Removed the vendor-specific types. 555 Added check for invalid TXT records and ones coming from wildcard 556 DNS. 558 Split the references into normative and informative. 560 B.5. Changes from 04 to 05 562 Small editorial changes received during IETF Last Call. 564 In Section 3, changed "another source" to "a preferred local set of 565 vouching services". 567 Added the section with ABNF to Section 4. 569 In Section 5, changed "exists at a VBR _name" to "exists at a name 570 from a VBR record". 572 In Section 5, added "If the RDATA in the TXT record contains multiple 573 character-strings..." and reorganized some surrounding text. 575 Added "Senders SHOULD use DKIM (and MAY use DomainKeys, SPF, or 576 SenderID) to give an accountable identity for the sender." to the 577 beginning of Section 7. 579 Added the IANA Considerations to add VBR-Info to the Message Header 580 Fields Registry. 582 Added reference to RFC 4407. 584 Added Murray Kucherawy to acknowledgements. 586 B.6. Changes from 05 to 06 588 Added the paragraph at the end of the introduction about recipients 589 using care when they select reputation providers. 591 Removed "The semantics of a message with non-identical mc= categories 592 are undefined" from the last paragraph of Section 4. 594 Added "The recipient looks up the domain name in the DNS in the exact 595 same manner it looks up all other domain names" near the beginning of 596 Section 5. 598 Changed "If more than one TXT record exists at a name from a VBR 599 record, the results are unspecified" to "The VBR record MUST have 600 only one TXT record" near the end of Section 5. 602 Near the end of Section 5, changed "valid domain name" to "valid host 603 name". 605 B.7. Changes from 06 to 07 607 In Section 4, changed "All three header fields" to "All three header 608 parameters". 610 In Section 4.1, changed *FWS to [FWS] in the ABNF. 612 Authors' Addresses 614 Paul Hoffman 615 Domain Assurance Council 617 Email: paul.hoffman@domain-assurance.org 619 John Levine 620 Domain Assurance Council 622 Email: john.levine@domain-assurance.org 624 Arvel Hathcock 625 Alt-N Technologies 627 Email: arvel.hathcock@altn.com