Skip to main content

2. Terminology and Definitions

This section defines terms used in the rest of the document.

DKIM is designed to operate within the Internet Mail service, as defined in [RFC5598]. Basic email terminology is taken from that specification.

Syntax descriptions use Augmented BNF (ABNF) [RFC5234].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. These words take their normative meanings only when they are presented in ALL UPPERCASE.

2.1. Signers​

Elements in the mail system that sign messages on behalf of a domain are referred to as Signers. These may be MUAs (Mail User Agents), MSAs (Mail Submission Agents), MTAs (Mail Transfer Agents), or other agents such as mailing list exploders. In general, any Signer will be involved in the injection of a message into the message system in some way. The key issue is that a message must be signed before it leaves the administrative domain of the Signer.

2.2. Verifiers​

Elements in the mail system that verify signatures are referred to as Verifiers. These may be MTAs, Mail Delivery Agents (MDAs), or MUAs. In most cases, it is expected that Verifiers will be close to an end user (reader) of the message or some consuming agent such as a mailing list exploder.

2.3. Identity​

A person, role, or organization. In the context of DKIM, examples include the author, the author's organization, an ISP along the handling path, an independent trust assessment service, and a mailing list operator.

2.4. Identifier​

A label that refers to an identity.

2.5. Signing Domain Identifier (SDID)​

A single domain name that is the mandatory payload output of DKIM and that refers to the identity claiming some responsibility for the message by signing it. It is specified in Section 3.5.

2.6. Agent or User Identifier (AUID)​

A single identifier that refers to the agent or user on behalf of whom the Signing Domain Identifier (SDID) has taken responsibility. The AUID comprises a domain name and an optional local-part. The domain name is the same as that used for the SDID or is a subdomain of it. For DKIM processing, the domain name portion of the AUID has only basic domain name semantics; any possible owner-specific semantics are outside the scope of DKIM. It is specified in Section 3.5.

Note that acceptable values for the AUID may be constrained via a flag in the public-key record. (See Section 3.6.1.)

2.7. Identity Assessor​

An element in the mail system that consumes DKIM's payload, which is the responsible Signing Domain Identifier (SDID). The Identity Assessor is dedicated to the assessment of the delivered identifier. Other DKIM (and non-DKIM) values can also be used by the Identity Assessor (if they are available) to provide a more general message evaluation filtering engine. However, this additional activity is outside the scope of this specification.

2.8. Whitespace​

There are three forms of whitespace:

  • WSP represents simple whitespace, i.e., a space (ASCII 0x20) or a tab (ASCII 0x09) character.

  • LWSP is linear whitespace, defined as WSP plus CRLF (carriage return/line feed) sequences that are part of header field folding.

  • FWS is folding whitespace. It allows multiple lines separated by CRLF to be joined together with at least one whitespace character.

The formal ABNF is (WSP and LWSP are for reference only):

WSP  = SP / HTAB
LWSP = *(WSP / CRLF WSP)
FWS  = [*WSP CRLF] 1*WSP

The definition of FWS is identical to that in [RFC5322] except for the exclusion of obs-FWS.

2.9. Imported ABNF Tokens​

The following tokens are imported from other RFCs as noted. Those RFCs should be considered definitive.

The following tokens are imported from [RFC5321]:

  • "local-part" (implementation warning: this permits quoted strings)
  • "sub-domain"

The following tokens are imported from [RFC5322]:

  • "field-name" (name of a header field)
  • "dot-atom-text" (in the local-part of an email address)

The following tokens are imported from [RFC2045]:

  • "qp-section" (one line of quoted-printable-encoded text)
  • "hex-octet" (a quoted-printable encoded octet)

INFORMATIVE NOTE: Note that the ABNF in [RFC2045] does not obey the rules of [RFC5234] and must be interpreted accordingly, particularly with respect to case folding.

Other tokens not defined herein are imported from [RFC5234]. These are intuitive primitives such as SP, HTAB, WSP, ALPHA, DIGIT, CRLF, etc.

2.10. Common ABNF Tokens​

The following ABNF tokens are used elsewhere in this document:

hyphenated-word = ALPHA [ *(ALPHA / DIGIT / "-") (ALPHA / DIGIT) ]
ALPHADIGITPS = (ALPHA / DIGIT / "+" / "/")
base64string = ALPHADIGITPS *([FWS] ALPHADIGITPS)
               [ [FWS] "=" [ [FWS] "=" ] ]
hdr-name = field-name
qp-hdr-value = dkim-quoted-printable  ; with "|" encoded

2.11. DKIM-Quoted-Printable​

The DKIM-Quoted-Printable encoding syntax is similar to that of Quoted-Printable described in [RFC2045, Section 6.7]: any character may be encoded as "=" followed by two hexadecimal digits from the alphabet "0123456789ABCDEF" (lowercase letters are not permitted) representing the hexadecimal-encoded integer value of that character. All control characters (those with values < %x20), 8-bit characters (values > %x7F), and the characters DEL (%x7F), SPACE (%x20), and semicolon (";", %x3B) MUST be encoded. Note that all whitespace, including SPACE, CR, and LF characters, MUST be encoded. After encoding, FWS MAY be added at arbitrary places in order to avoid excessively long lines; such whitespace is NOT part of the value and MUST be removed before decoding. Characters not listed as "mail-safe" in [RFC2049] SHOULD NOT be used.

ABNF:

dkim-quoted-printable = *(FWS / hex-octet / dkim-safe-char)
                        ; hex-octet is from RFC2045
dkim-safe-char = %x21-3A / %x3C / %x3E-7E
                 ; '!' - ':', '<', '>' - '~'

INFORMATIVE NOTE: DKIM-Quoted-Printable differs from Quoted-Printable as defined in [RFC2045] in several important ways:

  1. Whitespace in the input text (including CR and LF characters) MUST be encoded. [RFC2045] does not require such encoding, nor does it permit encoding of CR or LF characters that are part of a CRLF line break.

  2. Whitespace in the encoded text is ignored. This is to allow tags encoded in DKIM-Quoted-Printable to be wrapped as necessary. In particular, [RFC2049] requires line breaks in the input to be represented as physical line breaks; that is not the case here.

  3. The "soft line break" syntax ("=" as last non-whitespace character on a line) does not apply.

  4. DKIM-Quoted-Printable does not require that encoded lines be no more than 76 characters long (although there may be other requirements depending on the context in which the encoded text is being used).

Last updated on