跳到主要内容

2. 术语和定义

本节定义本文档其余部分使用的术语.

DKIM 设计为在 [RFC5598] 定义的 Internet Mail 服务内运行. 基本电子邮件术语取自该规范.

语法描述使用 Augmented BNF (ABNF) [RFC5234].

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" 和 "OPTIONAL" 应按 [RFC2119] 中的描述解释. 这些词只有在以 ALL UPPERCASE 形式出现时才具有规范性含义.

2.1. Signer​

邮件系统中代表某个域对消息进行签名的元素称为 Signer. 它们可以是 MUA (Mail User Agent), MSA (Mail Submission Agent), MTA (Mail Transfer Agent), 或邮件列表扩展器等其他代理. 一般来说, 任何 Signer 都会以某种方式参与把消息注入消息系统的过程. 关键问题是消息必须在离开 Signer 的管理域之前完成签名.

2.2. Verifier​

邮件系统中验证签名的元素称为 Verifier. 它们可以是 MTA, Mail Delivery Agent (MDA), 或 MUA. 在大多数情况下, 预期 Verifier 会靠近消息的最终用户 (读者), 或者靠近邮件列表扩展器等消费该消息的代理.

2.3. 身份​

个人, 角色或组织. 在 DKIM 语境中, 示例包括作者, 作者所在组织, 处理路径上的 ISP, 独立信任评估服务, 以及邮件列表运营者.

2.4. 标识符​

指代某个身份的标签.

2.5. 签名域标识符 (Signing Domain Identifier, SDID)​

一个单独的域名, 是 DKIM 的强制性载荷输出, 指代通过签名声明对消息承担某种责任的身份. 它在 Section 3.5 中规定.

2.6. 代理或用户标识符 (Agent or User Identifier, AUID)​

一个单独标识符, 指代由 Signing Domain Identifier (SDID) 代表并承担责任的代理或用户. AUID 由一个域名和一个可选 local-part 组成. 该域名与 SDID 使用的域名相同, 或者是其子域. 对于 DKIM 处理, AUID 中的域名部分只有基本域名语义; 任何可能的所有者特定语义都超出 DKIM 范围. 它在 Section 3.5 中规定.

注意, AUID 的可接受值可以通过 public-key record 中的一个标志进行约束. (见 Section 3.6.1.)

2.7. 身份评估器 (Identity Assessor)​

邮件系统中消费 DKIM 载荷的元素, 该载荷即负责的 Signing Domain Identifier (SDID). Identity Assessor 专门用于评估所交付的标识符. Identity Assessor 还可以使用其他 DKIM 值和非 DKIM 值 (如果可用), 以提供更通用的消息评估过滤引擎. 但是, 这种附加活动超出本规范范围.

2.8. 空白​

空白有三种形式:

  • WSP 表示简单空白, 即空格 (ASCII 0x20) 或制表符 (ASCII 0x09).

  • LWSP 是线性空白, 定义为 WSP 加上属于 header field 折叠的 CRLF (carriage return/line feed) 序列.

  • FWS 是折叠空白. 它允许用 CRLF 分隔的多行通过至少一个空白字符连接在一起.

正式 ABNF 如下 (WSP 和 LWSP 仅供参考):

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

除排除 obs-FWS 外, FWS 的定义与 [RFC5322] 中的定义相同.

2.9. 导入的 ABNF token​

以下 token 从所注明的其他 RFC 导入. 这些 RFC 应被视为权威定义.

以下 token 从 [RFC5321] 导入:

  • "local-part" (实现警告: 这允许带引号字符串)
  • "sub-domain"

以下 token 从 [RFC5322] 导入:

  • "field-name" (header field 的名称)
  • "dot-atom-text" (电子邮件地址 local-part 中)

以下 token 从 [RFC2045] 导入:

  • "qp-section" (一行 quoted-printable 编码文本)
  • "hex-octet" (一个 quoted-printable 编码 octet)

INFORMATIVE NOTE: 注意, [RFC2045] 中的 ABNF 不遵循 [RFC5234] 的规则, 因此必须相应解释, 尤其是在大小写折叠方面.

本文未定义的其他 token 从 [RFC5234] 导入. 这些是 SP, HTAB, WSP, ALPHA, DIGIT, CRLF 等直观原语.

2.10. 通用 ABNF token​

以下 ABNF token 在本文档其他位置使用:

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​

DKIM-Quoted-Printable 编码语法类似于 [RFC2045, Section 6.7] 中描述的 Quoted-Printable: 任意字符都可以编码为 "=" 后跟字母表 "0123456789ABCDEF" 中的两个十六进制数字 (不允许小写字母), 表示该字符的十六进制编码整数值. 所有控制字符 (值 < %x20), 8-bit 字符 (值 > %x7F), 以及字符 DEL (%x7F), SPACE (%x20) 和分号 (";", %x3B) 都 MUST 编码. 注意, 包括 SPACE, CR 和 LF 字符在内的所有空白都 MUST 编码. 编码后, 为避免行过长, MAY 在任意位置添加 FWS; 此类空白不是值的一部分, 并且 MUST 在解码前移除. SHOULD NOT 使用 [RFC2049] 中未列为 "mail-safe" 的字符.

ABNF:

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

INFORMATIVE NOTE: DKIM-Quoted-Printable 与 [RFC2045] 定义的 Quoted-Printable 有若干重要差异:

  1. 输入文本中的空白 (包括 CR 和 LF 字符) MUST 编码. [RFC2045] 不要求这种编码, 也不允许对属于 CRLF 换行的 CR 或 LF 字符进行编码.

  2. 编码文本中的空白会被忽略. 这样做是为了允许用 DKIM-Quoted-Printable 编码的 tag 按需换行. 特别地, [RFC2049] 要求输入中的换行表示为物理换行; 此处并非如此.

  3. "soft line break" 语法 (即 "=" 作为一行中最后一个非空白字符) 不适用.

  4. DKIM-Quoted-Printable 不要求编码后的行不超过 76 个字符 (但取决于编码文本使用的上下文, 可能存在其他要求).

最后于 更新