摘要

  • SMTP AUTH 把 SASL 认证置于邮件事务之前，使提交服务器能够依据经认证且获授权的身份决定是否允许中继，不再把某个网络地址当成天然通行证。
  • 这个成功状态只属于当前边界：认证身份、授权身份、信封发件人、可见作者、正文内容与后续路径仍是彼此独立的事实。

旧式入口只看得到连接

早期 SMTP 面向相互协作的主机。服务器可以接收发往本地域名的邮件，也可以按本地规则替别的主机转发。网络规模扩大以后，“能连上服务器”若仍等同于“可以向任意目的地中继”，开放中继便会把公共基础设施变成滥发工具。

按来源 IP 放行同样脆弱。合法用户一旦离开运营商接入网，就失去提交资格；处在被允许网段里的主机，却未必代表有权使用某个发件身份的人。POP-before-SMTP 曾以另一项服务的近期登录记录临时放行，但它靠地址与计时器拼接两个会话，并没有在邮件提交动作本身建立授权关系。

1999 年发布、后来由 RFC 4954 取代的 SMTP 认证扩展，把判断移进 SMTP 会话。服务器在 EHLO 响应中公布 AUTH 与可用的 SASL 机制，客户端在 MAIL FROM 之前选择机制并完成交换。成功后产生的不是“这封信已签名”，而是一个更小的会话事实：服务器接受了某个认证过程，并依照本地政策得出了一个授权身份。

这一事实足以控制中继入口，却不足以回答谁写了邮件。

SASL 把“是谁”拆成两个问题

SASL 区分认证身份与授权身份。前者属于被验证的凭证主体，后者是客户端请求以其名义行动的身份。凭证正确之后，服务器仍必须判断前者是否有权承担后者。

这不是术语上的细枝末节。一个系统账户可能代表队列提交许多用户的邮件；助理可能获准代某个邮箱提交，却不能使用另一个邮箱；服务凭证也可能在认证上完全有效，却请求了从未被授予的发件范围。SMTP AUTH 因而没有把登录名自动等同于 MAIL FROM、可见的 From 头或人类作者。

认证回答“哪个主体以哪种机制建立了这次会话”，授权回答“它在此处可以做什么”。信封和正文要在后续环节另行判断。若日志把这些身份压成一个字段，协议留下的边界就会被运营系统抹去。

587 端口把提交从传输中分离

RFC 6409 将邮件提交定义为独立服务。邮件用户代理把新消息送给邮件提交代理（MSA），MSA 可以拒绝或修正本地格式问题，再把邮件交入邮件传输代理网络。587 端口承载这类关系；互联网上 MTA 之间的传输仍是另一种信任场景。

默认情况下，如果会话既没有 SMTP AUTH，也没有受保护子网等独立授权，MSA 应以要求认证的状态拒绝 MAIL。这项规则并不要求所有互联网中继都把上游节点认证成最终用户。它把严格准入放在服务商与提交客户端直接相识的边界。

移动用户因此不必伪装成“仍在家里网络”。他可以通过提交服务证明账户资格，只得到该账户映射的中继能力。与此同时，入站 MTA 仍可为本地域名收信，而不向所有外部目的地开放转发。

端口号、扩展关键字与 SASL 机制名称由注册表协调；具体账户是否能代表财务邮箱、邮件列表或整个域提交，则始终属于 MSA 的本地政策。

传输保护改变可见能力

认证机制本身并不自动保护密码。RFC 4954 要求服务器只有在足够安全时才公布明文型机制，并允许 STARTTLS 之后的 EHLO 返回不同机制列表。于是“支持 AUTH”不是一个静态布尔值：TLS 前后、证书是否有效、客户端是否接受降级，都会改变可安全使用的能力。

RFC 8314 后来将邮件提交与访问中的明文视为过时，并明确了 587 上的 STARTTLS 与 465 上的隐式 TLS 路径。加密保护的是凭证交换与这一跳的会话内容；它仍不会把认证凭证变成正文的端到端签名。

AUTH= 记录的也只是一次声明

RFC 4954 还允许在 MAIL FROM 后携带 AUTH= 参数，记录被断言的原始提交者。若当前服务器无法以可信方式确定该身份，就应传递 AUTH=<>，而不是自作主张补出一个名字。只有处在受信环境的服务器，才可将该声明转交给下一跳。

这条规定保留了不确定性。身份来源于何处、哪一跳验证过它、哪一跳只是转发它，必须能够分开。RFC 3848 登记的 ESMTPA 与 ESMTPSA 传输类型也只说明接收这一跳用了认证，或同时用了认证与 TLS；它们不能证明整个路线，也不能认证作者。

SMTP AUTH 最可靠的地方，正是成功登录仍小于一枚签名。它可以开放入口、选定政策并留下可审计的单跳证据；它不能认证每个发件字段、人类意图、正文或后续中继。

来源