Vouch By Reference
updated by
- rfc-8553 — DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names
Extracted elements (24)
The label "_vouch" was chosen because any domain name containing it as a label cannot be a valid hostname, ensuring there can never be accidental overlap with a valid host name and making it safe to assume any TXT record under a _vouch-labeled name conforms to this specification.
The mc= content-type element is self-asserted by the sender to create an audit trail. This allows certifiers to catch senders who mislabel mail types (e.g., labeling advertising as transactional) and revoke certification, even though the value cannot be independently verified at query time.
VBR uses DNS TXT records for certification distribution to leverage existing DNS efficiencies, reliability, and negative caching (RFC 2308). The lookup is fast and certifiers can add or remove client records immediately.
A VBR domain MUST have only one TXT record at the _vouch DNS name; the presence of more than one TXT record is disallowed.
All three header parameters in the VBR-Info header field (md=, mc=, mv=) are mandatory; there is no default for the md= domain.
All VBR-Info header fields in a single message MUST have identical mc= values. Verifiers MUST accept the three fields in any order and SHOULD ignore unrecognized fields.
If a message has more than one VBR-Info header field, verifiers SHOULD check each in turn or in parallel until a satisfactory certifier is found or all fields have been checked.
If the RDATA in a DNS TXT record contains multiple character-strings (per RFC 1035 Section 3.3), the code handling the DNS reply MUST assemble all those text blocks into a single string before any syntactic verification takes place.
Senders SHOULD use DKIM to provide an accountable identity, and MAY use DomainKeys, SPF, or Sender ID as alternative validation mechanisms.
The VBR-Info header field SHOULD be included in the set of header fields protected by DKIM (or DomainKeys) to prevent a malicious party from altering or adding bogus VBR-Info header fields.
VBR-Info is a trace header field and SHOULD be added at the top of the message header fields, following RFC 5322 conventions for trace fields.
Verifiers MUST check that the DNS TXT record consists of strings of lowercase letters separated by spaces, and discard any records not in that format. This defends against misconfigured records and records synthesized from DNS wildcards.
When DKIM is the validation mechanism, VBR's md= MUST match the domain name from the DKIM-Signature header field: the i= domain if present, otherwise the d= domain.
When Sender ID is the validation mechanism, VBR's md= MUST match the domain in the Purported Responsible Address (RFC 4407), and the Sender ID process must produce a "pass" result.
When SPF is the validation mechanism, VBR's md= MUST be the same value as the domain in the SMTP MAIL command's reverse-path address, and the SPF process must produce a "pass" result for the domain to be valid.
Three message content types are defined: "all" (all mail from the sender), "list" (bulk mail sent to multiple recipients that is identical or very similar), and "transaction" (transactional messages that are responses to specific user actions or account events).
To verify a VBR claim, a receiver constructs a DNS name by concatenating: the accountable domain, the literal label "_vouch", and the certifier's hostname (e.g., somebank.example._vouch.certifier-a.example), then queries it for a DNS TXT record.
VBR-Info is a new RFC 5322 mail header field used by senders to assert which third-party certification services will vouch for their messages. It contains three components: the accountable domain (md=), the message content type (mc=), and a colon-separated list of certifier domains (mv=).
IANA registered the "VBR-Info" header field in the Message Header Fields Registry (RFC 3864). The applicable protocol is "mail", status is "standard", and the specification document is RFC 5518.
Implementations SHOULD limit the number of VBR-Info header fields they process per message to protect against make-work or denial-of-service attacks that flood a message with many certifier lookups.
Receivers MUST ignore certifiers they do not explicitly trust; a bad actor could otherwise add a self-controlled authority to the mv= list and vouch for its own mail. Only certifiers from a locally trusted set should be acted upon.
Recipients who use VBR vouching results to adjust spam scores place significant operational trust and power in vouching services. Recipients should select services with care and consider using multiple vouching services to avoid a single point of failure.
The ABNF defines vbr-info-header as one or more FWS-delimited semicolon-terminated elements (md-element, mc-element, mv-element). The type-string is constrained to exactly three values: "all", "list", or "transaction". The certifier-list is domain-name *(':' domain-name).
The VBR-Info header field has the format: `VBR-Info: md=<domain>; mc=<type-string>; mv=<certifier-list>;`. The certifier-list is one or more domain names separated by colons. No white space is permitted within any of the three parameter values.