rfc-6212

Authentication-Results Registration for Vouch by Reference Results

M. Kucherawy
date2011-04 streamIETF wgnon working group statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc6212 doi10.17487/RFC6212
This memo updates the registry of properties in Authentication- Results: message header fields to allow relaying of the results of a Vouch By Reference query. [STANDARDS-TRACK]

Extracted elements (11)

design-rationale §3

Reactions to VBR results in an Authentication-Results header are deliberately left unspecified, as they are entirely a matter of local policy at the receiver. This keeps the relay mechanism generic and policy-neutral.

email

design-rationale §3

VBR queries are typically performed at an inbound border mail gateway, but the result needs to be communicated to internal mail entities such as filters or user agents. The Authentication-Results header field provides a machine-readable mechanism already in place for relaying such assessments, making it the natural vehicle for VBR results.

email

interoperability-note §4

When a VBR-Info header field is present, 'header.md' is typically taken from the 'md' tag and 'header.mv' from one of the 'mv' tag values; however, VBR permits alternative subject-domain and voucher-selection mechanisms that may override or ignore the VBR-Info field entirely.

email

normative-requirement §4 MUST

If 'header.md' is present in an Authentication-Results field for a VBR result, its value MUST be the DNS domain name about which the VBR query was made.

email, dns

normative-requirement §4 MUST

If 'header.mv' is present in an Authentication-Results field for a VBR result, its value MUST be the DNS domain name that was queried as the potential voucher for the 'header.md' domain.

email, dns

normative-requirement §4 MAY

When VBR query mechanisms other than reading a VBR-Info header field are applied (e.g., locally configured policy or queries absent any VBR-Info field), the verifying server MAY generate an Authentication-Results field to relay the results of the VBR query.

email

protocol-element §4

Five result codes are defined for the 'vbr' method: 'none' (no valid VBR-Info or queryable domain found), 'pass' (vouching service gave positive response), 'fail' (negative response or conflicting 'mc' values in multiple VBR-Info headers), 'temperror' (transient DNS error), 'permerror' (permanent DNS error).

email, dns

protocol-element §4

The 'vbr' authentication method is defined for use in Authentication-Results header fields. It reports the outcome of a Vouch By Reference DNS query, including which domain was vouched and which vouching service was queried, using the 'header.md' and 'header.mv' properties.

email, dns

registry §5

RFC 6212 adds five result codes to the IANA 'Email Authentication Result Names' registry for use with the 'vbr' method: none, pass, fail, temperror, and permerror. These reuse existing code tokens from RFC 5451 but associate them with the new 'vbr' method.

email, registry

registry §5

RFC 6212 adds the 'vbr' method and associated properties 'header.md' and 'header.mv' to the IANA 'Email Authentication Methods' registry originally created by RFC 5451. 'header.md' carries the DNS domain name subject of the VBR query; 'header.mv' carries the DNS domain name of the vouching entity.

email, registry

security-consideration §6

RFC 6212 creates a mechanism for relaying VBR results using the Authentication-Results structure defined in RFC 5451. The security considerations of both RFC 5451 (Authentication-Results) and RFC 5518 (VBR) apply and should be consulted; no additional security analysis is provided here.

email, security