7Network Working Group P. Hoffman
8Request for Comments: 5518 J. Levine
9Category: Standards Track Domain Assurance Council
19 This document specifies an Internet standards track protocol for the
20 Internet community, and requests discussion and suggestions for
21 improvements. Please refer to the current edition of the "Internet
22 Official Protocol Standards" (STD 1) for the standardization state
23 and status of this protocol. Distribution of this memo is unlimited.
27 Copyright (c) 2009 IETF Trust and the persons identified as the
28 document authors. All rights reserved.
30 This document is subject to BCP 78 and the IETF Trust's Legal
31 Provisions Relating to IETF Documents in effect on the date of
32 publication of this document (http://trustee.ietf.org/license-info).
33 Please review these documents carefully, as they describe your rights
34 and restrictions with respect to this document.
36 This document may contain material from IETF Documents or IETF
37 Contributions published or made publicly available before November
38 10, 2008. The person(s) controlling the copyright in some of this
39 material may not have granted the IETF Trust the right to allow
40 modifications of such material outside the IETF Standards Process.
41 Without obtaining an adequate license from the person(s) controlling
42 the copyright in such materials, this document may not be modified
43 outside the IETF Standards Process, and derivative works of it may
44 not be created outside the IETF Standards Process, except to format
45 it for publication as an RFC or to translate it into languages other
50 This document describes the Vouch By Reference (VBR) protocol. VBR
51 is a protocol for adding third-party certification to email. It
52 permits independent third parties to certify the owner of a domain
53 name that is associated with received mail.
58Hoffman, et al. Standards Track [Page 1]
60RFC 5518 VBR April 2009
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 .................................................10
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 .....................................12
114Hoffman, et al. Standards Track [Page 2]
116RFC 5518 VBR April 2009
121 Vouch By Reference, or VBR, is a protocol for adding third-party
122 certification to email. Specifically, VBR permits independent third
123 parties to certify the owner of a domain name that is associated with
124 received mail. VBR may be performed anywhere along the email transit
125 path, by any capable receiving module, either within the handling
126 service or by end-user software.
128 VBR accomplishes this with a two-part protocol:
130 o In the first part, a sender affixes VBR information to email
131 messages. The VBR information says which domain certification
132 services the sender believes will vouch for email traffic
133 associated with that sender.
135 o In the second part, the receiver queries one or more certification
136 services to obtain information about the identity that has been
137 associated with a received message. This latter protocol uses the
138 DNS to distribute the certification information.
140 A sender provides certification attestations through the use of a new
141 RFC 5322 ([RFC5322]) mail header field, "VBR-Info:". This header
142 field contains the names of services that the sender claims will
143 vouch for it, and the particular type of content of the message. A
144 queried, third-party, DNS-based certification service can respond
145 with a list of the types of message content it will vouch for, such
146 as "transactional mail from somebank.example" and/or "all mail from
147 anotherbank.example".
149 A prerequisite for successful VBR operation is validation of the
150 identity associated with the message. VBR is based on the use of
151 domain names as identifiers, and permits multiple methods of
152 obtaining and validating domain names. The validation methods are
153 described in the "Obtaining a Useful Domain Name" section below.
155 The sender performs two steps:
157 1. Adds a VBR-Info header field to its message
159 2. Protects the message, as appropriate
161 If a recipient uses the results of vouching to adjust spam scores on
162 incoming email, that recipient is placing a great deal of operational
163 trust and power in the vouching service. Therefore, recipients need
164 to select such services with care. Further, such recipients may want
165 to select more than one vouching service in order to avoid a single
166 point of failure for setting spam scores.
170Hoffman, et al. Standards Track [Page 3]
172RFC 5518 VBR April 2009
177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
179 document are to be interpreted as described in [RFC2119].
1812. Use of the VBR-Info Header Field
183 A sender uses VBR to indicate which domain certification services the
184 sender believes will vouch for a particular piece of mail. The
185 certification service uses VBR to state for which signatures it will
186 vouch. This protocol uses the DNS to distribute the certification
189 A message may have multiple VBR-Info header fields. This means that,
190 in the terminology of RFC 5322, VBR-Info is a "trace header field"
191 and SHOULD be added at the top of the header fields.
193 The content of the VBR-Info header field is a list of three elements:
195 o The accountable domain
197 o The type of content in the message
199 o A list of domain names of services that the sender expects to
200 vouch for that kind of content
202 The accountable domain is given as md= followed by a domain name.
203 The content type is given as mc= followed by a string; the defined
204 values of that string are found below. The list of services is given
205 as mv= followed by a colon-separated list of domain names.
207 The formal syntax of the header field is defined in Section 4.
211 A message receiver uses VBR to determine certification status by
212 following these steps:
214 1. Extracts the domain to certify and the type of message content
216 2. Verifies legitimate use of that domain using one or more
217 authentication mechanisms as described herein
219 3. Obtains the name of a vouching service that it trusts, either
220 from among the set supplied by the sender or from a locally
221 defined set of preferred vouching services
226Hoffman, et al. Standards Track [Page 4]
228RFC 5518 VBR April 2009
231 4. Queries the vouching service to determine whether the vouching
232 service actually vouches for that type of content for that
2354. The VBR-Info Header Field
237 The VBR-Info header field has the following format:
239 VBR-Info: md=<domain>; mc=<type-string>; mv=<certifier-list>;
241 where <domain> is the domain for which vouching is offered, <type-
242 string> is the content type of the message, and <certifier-list> is a
243 list of domain names of certification providers that the sender
244 asserts will vouch for this particular message. The structure of the
245 <certifier-list> is one or more domain names with a colon (":")
246 between each. The elements in the <domain>, <type-string>, and
247 <certifier-list> must not have any white space in them.
249 For example, assume that the signer has two companies that are
250 willing to vouch for its transactional notices: certifier-a.example
251 and certifier-b.example. The signer would add the following to the
252 header of its outgoing message.
254 VBR-Info: md=somebank.example; mc=transaction;
255 mv=certifier-a.example:certifier-b.example;
257 All three header parameters in the VBR-Info header are mandatory. In
258 particular, there is no default for the md= domain.
260 Upper and lowercase characters in a VBR-Info header field are
261 equivalent, although conventionally the contents are all in lower
262 case. For upward compatibility, verifiers MUST accept the fields in
263 any order and SHOULD ignore any fields other than the three defined
266 If a message has more than one VBR-Info header field, verifiers
267 SHOULD check each in turn or in parallel until either a satisfactory
268 certifier is found or all the header fields have been checked. All
269 of the VBR-Info header fields in a single message MUST have identical
2724.1. Syntax of VBR-Info Header Fields
274 In the ABNF below, the ALPHA and DIGIT tokens are imported from
275 [RFC5234], and the FWS and domain-name tokens are imported from
282Hoffman, et al. Standards Track [Page 5]
284RFC 5518 VBR April 2009
287 vbr-info-header = "VBR-Info:" 1*([FWS] element [FWS] ";")
288 element = md-element / mc-element / mv-element
290 md-element = "md=" [FWS] domain-name
292 mc-element = "mc=" [FWS] type-string
293 type-string = "all" / "list" / "transaction"
295 mv-element = "mv=" [FWS] certifier-list
296 certifier-list = domain-name *(":" domain-name)
300 When a recipient wants to check whether a certification claim is
301 valid, it compares the list in the message to the list of services it
302 trusts. For each service that is on the intersection of the two
303 lists, it marshals a domain name to look up that consists of the
304 following DNS labels (from left to right):
306 o the domain name that asserts it can be certified
308 o _vouch (a string literal)
310 o the host name of the vouching service
312 This domain name is queried for a DNS TXT record. The recipient
313 looks up the domain name in the DNS in the exact same manner it looks
314 up all other domain names.
316 For example, if a message signed by somebank.example contained the
317 VBR-Info header field above, the receiver might look up either or
318 both of the following names, depending on which vouching service it
321 somebank.example._vouch.certifier-b.example
322 somebank.example._vouch.certifier-a.example
324 If the DNS TXT record exists, it contains a space-delimited list of
325 all the types that the service certifies, given as lowercase ASCII.
326 For example, the contents of the TXT record might be:
330 In the example above, the receiver checks whether or not either
331 certifier vouches for "transaction" mail. That would be indicated by
332 either of the following types: "all" or "transaction" ("all"
333 indicates that the certifier vouches for all message types sent by
334 the domain in question). If either of those types appear in either
338Hoffman, et al. Standards Track [Page 6]
340RFC 5518 VBR April 2009
343 TXT record, the certifier has vouched for the validity of the
344 message. Of course, the recipient needs to ignore services that it
345 does not trust; otherwise, a bad actor could just add an authority
346 that it has set up so that it can vouch for itself.
348 The name for the label _vouch was chosen because any domain name that
349 includes it as one of its labels cannot be a valid host name. There
350 will never be any accidental overlap with a valid host name.
351 Further, it is safe to create a rule that says that a TXT DNS record
352 that comes from a domain name that includes a _vouch label will
353 always have the structure defined in this document.
355 If the RDATA in the TXT record contains multiple character-strings
356 (as defined in Section 3.3 of [RFC1035]), the code handling that
357 reply from DNS MUST assemble all of these marshaled text blocks into
358 a single one before any syntactical verification takes place.
360 Verifiers MUST then check that the TXT record consists of strings of
361 lowercase letters separated by spaces, and discard any records not in
362 that format. This defends against misconfigured records and
363 irrelevant records synthesized from DNS wildcards.
365 The VBR record MUST have only one TXT record.
367 This query method relies on the considerable advantages of existing
368 DNS efficiencies, reliability, and experience. The lookup is very
369 efficient, and certifiers can add and delete client records as
370 quickly as they want. The lookup also leverages the DNS's negative
3736. Types of Message Content
375 This section describes the types of content for which a certifier can
376 vouch. While the rest of the VBR specification is mostly technical
377 and precise, describing the types of contents in mail messages is
378 inherently open to interpretation. Thus, this section makes
379 distinctions as specifically as possible, but the reader needs to
380 understand that these semantic definitions can be interpreted in very
381 different ways by different people.
383 Note that the value in the mc= element is self-asserted. The purpose
384 of this element is for auditing. There will likely be cases where a
385 certifier will vouch for one type of a sender's mail (such as
386 transactional mail) but not another type (such as advertising). A
387 sender who cannot get anyone to certify its advertising mail, but has
388 a certifier for its transactional mail, might be tempted to cheat and
394Hoffman, et al. Standards Track [Page 7]
396RFC 5518 VBR April 2009
399 mislabel it as transactional. The mc= element creates an the audit
400 trail to help their certifiers catch such cheating and allow the
401 removal of the certification for the transactional mail.
403 Three types of content are defined.
407 "all" means all mail from the sender.
411 "list" is the category for email sent to multiple recipients where
412 each piece of mail is identical or is very similar to the others.
416 "transaction" is the category for transactional messages. This is a
417 response to a specific action of the user, or a notice about an event
418 in the user's account at the sender.
4207. Obtaining a Useful Domain Name
422 VBR relies on having a domain name that specifies a party that is
423 accountable for the message. This requires obtaining the domain name
424 and possessing a strong basis for believing that the use of the
425 domain name is valid, that is, that it has not been spoofed.
427 There are different ways to achieve this and this section discusses
428 the allowed mechanisms. Senders SHOULD use Domain Keys Identified
429 Mail (DKIM) (and MAY use DomainKeys, Sender Policy Framework (SPF),
430 or SenderID) to give an accountable identity for the sender.
434 DomainKeys Identified Mail (DKIM), [RFC4871], defines an accountable
435 identity by associating a domain name with the message. It provides
436 assurance that the association is valid through a public-key-based
437 authentication mechanism.
439 o When DKIM is the validation mechanism, VBR's md= MUST match the
440 domain name taken from one of the DKIM-Signature header fields.
441 If the DKIM signature contains an i= field, the domain name from
442 that field is used; otherwise, the domain name from the DKIM
443 signature d= field is used.
450Hoffman, et al. Standards Track [Page 8]
452RFC 5518 VBR April 2009
455 o The VBR-Info header field SHOULD be included in the set of header
456 fields protected by DKIM to prevent a malicious party from
457 changing the contents of the VBR-Info header field or adding bogus
458 VBR-Info header fields.
460 o The VBR-Info header field SHOULD be added in the header
461 immediately below the corresponding DKIM-Signature header field.
463 If the DKIM signature validates, the domain name taken from that
464 signature is valid for use with VBR.
468 DomainKeys (DK), [RFC4870], defines an accountable identity by
469 associating a domain name with the message in the d= tag of the
470 DomainKey-Signature header field. It provides assurance that the
471 association is valid through a public-key-based authentication
474 o When DomainKeys is the validation mechanism, VBR's md= MUST be the
475 same value as the domain name found in the DomainKey-Signature d=
478 o The VBR-Info header field SHOULD be included in the set of header
479 fields protected by DK to prevent a malicious party from changing
480 the contents of the VBR-Info header field or adding bogus VBR-Info
483 o The VBR-Info header field SHOULD be added immediately below the
484 corresponding DomainKey-Signature header field.
486 If the DomainKeys signature validates, the domain in the d= tag is
487 valid for use with VBR.
491 Sender Policy Framework (SPF), [RFC4408], defines an accountable
492 identity by using an existing message address and querying the DNS to
493 discover whether it is valid for SPF use.
495 When SPF is the validation mechanism, VBR's md= MUST be the same
496 value as the domain name in the <reverse-path> address that is the
497 first parameter to the SMTP MAIL command.
499 A domain is valid for use with VBR only when the SPF process produces
506Hoffman, et al. Standards Track [Page 9]
508RFC 5518 VBR April 2009
513 Sender ID, [RFC4406], defines an accountable identity by using an
514 existing message address known as the Purported Responsible Address
515 ([RFC4407]) and querying the DNS to discover whether it is valid for
518 When Sender ID is the validation mechanism, VBR's md= MUST be the
519 same value as the domain name in the Purported Responsible Address in
522 A domain is valid for use with VBR only when the Sender ID process
523 produces a "pass" result.
5258. Security Considerations
527 VBR is used to allow users to trust independent third parties to
528 certify the owner of a domain name that is associated with received
529 mail. The party validating the mail might use that trust
530 relationship to perform actions that affect the security of their
533 The receiver of a message with a VBR-Info header field MUST ignore
534 certifiers that it does not trust; otherwise, a bad actor could just
535 add an authority that it has set up so that it can vouch for itself.
537 Implementations SHOULD limit the number of VBR-Info header fields
538 they process in a single message in order to protect themselves from
539 a make-work or denial-of-service attack.
5419. IANA Considerations
543 IANA registered the VBR-Info header field in the Message Header
544 Fields Registry ([RFC3864]) as follows:
546 Header field name: VBR-Info
548 Applicable protocol: mail
552 Author/Change controller: IETF
554 Specification document(s): RFC 5518
556 Related information: none
562Hoffman, et al. Standards Track [Page 10]
564RFC 5518 VBR April 2009
56910.1. Normative References
571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
572 Requirement Levels", BCP 14, RFC 2119, March 1997.
574 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
575 Specifications: ABNF", STD 68, RFC 5234, January 2008.
577 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322,
58010.2. Informative References
582 [RFC1035] Mockapetris, P., "Domain names - implementation and
583 specification", STD 13, RFC 1035, November 1987.
585 [RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
586 NCACHE)", RFC 2308, March 1998.
588 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
589 Procedures for Message Header Fields", BCP 90, RFC 3864,
592 [RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
593 RFC 4406, April 2006.
595 [RFC4407] Lyon, J., "Purported Responsible Address in E-Mail
596 Messages", RFC 4407, April 2006.
598 [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF)
599 for Authorizing Use of Domains in E-Mail, Version 1",
600 RFC 4408, April 2006.
602 [RFC4870] Delany, M., "Domain-Based Email Authentication Using
603 Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
606 [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
607 J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
608 Signatures", RFC 4871, May 2007.
618Hoffman, et al. Standards Track [Page 11]
620RFC 5518 VBR April 2009
623Appendix A. Acknowledgements
625 Many members of the Domain Assurance Council contributed to the
626 design of the protocol and the wording of this document. In
627 addition, constructive suggestions were received from Jim Fenton and
633 Domain Assurance Council
635 EMail: paul.hoffman@domain-assurance.org
639 Domain Assurance Council
641 EMail: john.levine@domain-assurance.org
647 EMail: arvel.hathcock@altn.com
674Hoffman, et al. Standards Track [Page 12]