RFC 6008 Proposed Standard Authentication

Authentication-Results Registration for Differentiating among Cryptographic Results

This memo updates the registry of properties in Authentication- Results: message header fields to allow a multiple-result report to distinguish among one or more cryptographic signatures on a message, thus associating specific results with the signatures they represent. [STANDARDS-TRACK]

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
September 2010
Authors
M. Kucherawy
Read it
rfc-editor.org · DOI

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 3 must, 1 should, 0 may.

4 Definition

  • MUSTThe value associated with this item in the header field MUST be at least the first eight characters of the digital signature (the "b=" tag from a DKIM-Signature) for which a result is being relayed, and MUST be long enough to be unique among the results being reported.
  • MUSTWhere the total length of the digital signature is fewer than eight characters, the entire signature MUST be included.
  • MUSTMatching of the value of this item against the signature itself MUST be case-sensitive.
  • SHOULDIf an evaluating agent observes that, despite the use of this disambiguating tag, unequal authentication results are offered about the same signature from the same trusted authserv-id, that agent SHOULD ignore all such results.

Every current email RFC