上周有个客户的运维把发信程序从 25 端口改到 587，账号密码都填了，日志里还是 530 5.7.0。他把日志甩过来，问是不是我们把认证关了。

认证没关。他那套代码从头到尾没发过 AUTH——EHLO、MAIL FROM、RCPT TO、DATA，四步走完就等 250。这套流程在 25 端口上跑了七八年，一次没出过事。同一个程序换个端口就死，这件事本身比故障有意思：

25 和 587 之间隔着的，是两种角色

我早年以为 MSA 就是“给客户端用的 SMTP”，把 25 那套东西换个号、加个登录框。后来把 RFC 6409 从头读了一遍才明白，它拆的是两种信任关系，跟代码路径没多大关系。

一台 MTA 收到连接，要回答的问题是：这封信是不是发给我的用户的。看的是 RCPT TO 后面的域。属于自己管的域，收下；不属于，就问一句你凭什么让我用带宽和信誉帮你转发，答不上来就拒。整个判断里，发件人是谁根本不重要——外域任何一台服务器都可能来信，你不可能要求对方先证明身份，那等于把收信关掉。

麻烦出在早年所有人挤同一个端口。客户端连 25，服务器之间也连 25。前者要求只让内部人进，后者要求对全网开放。一个端口背两种信任级别，只能取宽的那个。开放中继的年代，这条缝被人拿来塞垃圾邮件，发信成本接近零，成本转嫁给被中继的那台机器。后来 ISP 陆续封掉 25 的出站连接，出差、换网络、住酒店，信发不出去。收信和发信第一次在物理上打架。

1998 年 12 月的 RFC 2476 干的事就是拆：新开 587，定义 MSA 这个角色，只接 MUA 提交，不负责往别的域投递。SMTP 的命令集本来够用，拆开的理由在信任模型上，跟协议能力无关。

2476 有个硬伤，它出生时 SMTP AUTH 还没标准化（RFC 2554 要到 1999 年 3 月才发布，今天这套机制是 RFC 4954 定义的）。最早那批 MSA 手里没有客户端普遍支持的认证手段，只能靠 IP 白名单、内网位置，或者“先 POP 再 SMTP”这种土办法。能连上 587 的人多半已经在可信网段里，认证等于没做。端口分开了，门还虚掩着。

2006 年 4 月的 RFC 4409 把认证、地址规范、消息处理补齐，同时收进一个叫 SUBMITTER 的扩展，定义在 RFC 4405，实验状态。想法很直接：在 MAIL FROM 里加个参数，写明“最近一次把这封信塞进传输流的是谁”，接收方不用等收完整封信就能预判发件人认证该怎么判。听上去是给认证打了个提前量。

它没成。2012 年 RFC 6686 给 2006 年那批实验做总结，数据很干脆：全网扫下来，在 EHLO 里报 SUBMITTER 的 MTA 不到 5%，找到的实现只有三个。2011 年 11 月的 RFC 6409 取代了 4409（4409 当年取代的是 2476），成了今天 MSA 的定义文本。它把 SUBMITTER 相关内容整段删掉，现在翻全文，这个词一次都不出现。

失败的原因比它当初怎么设计更值得看。同一批实验里有 SPF，同样 2006 年、同样实验状态，SPF 活成了标准，SUBMITTER 死了。差别不在谁更聪明。SPF 落地只需要域名的管理者往 DNS 加一条记录，一个人一下午干完，干完立刻见效。SUBMITTER 要 MUA 改（改了不获益），要中间每一跳中继原样透传（不认识的参数按规矩该忽略，透传还得防伪造），要接收方愿意相信一个没有密码学依据的声明。三方都得先动，没有一方先动就能拿到好处。

更麻烦的是模型错位。SMTP 扩展是逐跳协商的：EHLO 报能力，每一跳自己决定支不支持。SUBMITTER 想表达的是端到端的事实——只有第一跳知道提交者是谁，这个事实要穿过整条链。拿逐跳的机制承载端到端的信息，中间哪一跳不配合，参数就退化成一句没人读的注释。实现层面没出什么问题，错在拿错了工具。

真正把发件人认证做成的是另一条路：SPF 查域、DKIM 签名、DMARC 定策略。它们不要求全链路改协议，只要求发信的域自己签字、收信的方自己查 DNS。成本落在愿意承担的人身上，所以推得动。

25 是 MTA 对 MTA，陌生机器之间说话，唯一一个必须无认证对全网开放的门。不开放就收不到外域来信。

587 是 MUA 对 MSA。先 STARTTLS 升级加密，再 AUTH，然后才能 MAIL FROM。RFC 6409 写得很清楚：默认情况下没认证就给 530，除非 MSA 已经用别的方式确认了授权，比如对方在受保护的内网里。

465 也是 MUA 对 MSA，但 TLS 从第一个字节就开始。它的命不太好：九十年代末作为 smtps 注册，后来 STARTTLS 成了标准路径，它被判定为重复实现，注册撤掉。客户端不管这套，十几年一直在用。2017 年底 IANA 重新分配，2018 年 1 月的 RFC 8314 正式确认它可以用于隐式 TLS 的提交，这份文档顺带还更新了 6409。

465 回来，我认为根子在 STARTTLS 的模型：先明文握手，再协商升级，中间人只要让客户端看不见服务端的能力，客户端就老老实实退回明文，协议里没有一个“必须加密、否则别发”的硬点。465 没有明文阶段，也就没有降级空间。RFC 8314 的口气很硬，明文提交该结束了。新部署我倾向 465——STARTTLS 当然也能配得很严，但它那个模型天生允许例外，465 没有例外可给，运维少一类事故。

这是最容易混的地方。25 端口的 MTA 查收件人域：这封信是不是发给我的。是就收，不是就看有没有中继授权，没有就 554 5.7.1。MSA 查发件人身份：这封信是不是你发的。AUTH 上来的账号，和 MAIL FROM、From 里的地址对不对得上，对不上就 550 5.7.1。

一个问“给谁”，一个问“谁给的”，

。MSA 基本不看收件人域，收件人写哪儿都行——它干的是替一个有账号的人发信，不负责帮陌生人转发。

这个分工有个常被忽略的后果：提交时返回 250，只代表“这封信我接了”，不代表“对方收到了”。MSA 把责任接过来，投递、重试、退信都在后面。很多业务系统把发信接口的返回值当送达回执用，这个误解在排障时能把人带沟里。

RFC 6409 列了一串 MSA 可以做的修改：补 Date，补 Message-ID，身份已知而 From 没给时补一个 Sender，做传输编码，按本地策略改写地址，必要时加签名。补 From 这件事规范里没有明文，不少实现是拿认证身份直接补的——业界常见，边界也确实模糊。RFC 5321 对中继的要求是另一个方向：除了加 Received、Return-Path 这类轨迹头，不得改动消息内容。

我一开始以为这是权限大小的区别，后来发现是身份的区别。MSA 是作者这一侧的代理，替用户干活，而用户交上来的常常是半成品：客户端不知道自己的时区，Date 就是空的；有些客户端压根不生成 Message-ID。把这些补完是它的职责。中继是搬运工，跟内容没有关系，一改，端到端的完整性就没了。

还有一个规范没单列、但所有 MSA 都在做的动作：摘掉 Bcc。Bcc 在提交阶段是给服务器看的指令——这些人也要收，别让他们互相看见。信一旦拆成多份投递出去，这个头还留着，密送名单就跟着泄露。它必须在离开 MSA 之前消失。这种事不写进条款，因为不改就是事故。

改写权有后遗症，边界很模糊。补一个 From 和改一个 From，差在哪？不同实现给的答案不一样。上了 DKIM 之后，模糊变成硬约束：签名必须发生在所有改写之后，MSA 成了签名前最后一道闸口。位置放错，整条链的密码学校验全崩，而且崩得毫无提示，只在接收方的过滤器里表现为“签名无效”。

RFC 1870 给了 SIZE：EHLO 时服务端广播上限，客户端在 MAIL FROM 里带上预估字节数，超了直接 552 5.3.4。

这里有个几乎每张工单都会踩的坑：用户看到的附件大小，和线上真正传输的字节数，不是一回事。MIME 编码会膨胀。base64 用四个字符表示三个字节，光编码就多出三分之一，还没算按行折断插入的换行；quoted-printable 对二进制内容更差。一个 20MB 的 PDF，base64 之后接近 27MB。SIZE 算的是编码后的整封信，包含头部、分隔线和每一段的编码。

所以“支持 25MB 附件”这种产品口径，和服务器上配的 SIZE 数值，中间必须留余量。反过来，SIZE 配 25MB 的服务器，用户实际能塞进去的附件大约 18MB。这两个数字在文档里被混用了十几年，每次都要重新解释。顺带一句，552 5.3.4 是永久错误，客户端不该重试；可不少客户端把 5xx 一律当网络抖动，原地重试三次，用户看到“卡住了”，我们看到三条一模一样的拒收日志。

MSA 面对的是一个账号的多个客户端。手机在同步，桌面客户端挂着 IDLE，网页版开着标签页，三个会话同时发信是常态，再叠加群发，一个账号瞬间能占满连接。

所以要控制的东西很具体：单账号并发会话数、单位时间的发信量和收件人总数、单封信的收件人上限。超了返回 421 或 452，都是 4xx，让客户端等一会儿再来。

为什么给临时错误？账号按计费和信誉算，跟设备数量无关。一个账号被盗、被拿去群发，毁的是整个 IP 池的信誉，牵连所有用户。限流冲的是共享资源去的，谁撞上谁被拦。

代价是这套控制有一半掌握在客户端手里。421 是“我要关连接”，最粗暴，很多客户端收到就弹框，不重试；452 精细些，也要客户端认。我见过不少系统限流配得漂亮，实际效果接近零，因为客户端根本不退避，用户只觉得“这邮箱时好时坏”。

响应码的语义在提交这条路上漂移了。策略类拒绝集中在 5.7.x 和 4.7.x：认证前发 MAIL FROM 得 530 5.7.0，没资格中继得 554 5.7.1，这些好认。

难认的是 550。在 MTA 之间，550 通常意味着这封信传不过去，比如 550 5.1.1 收件人不存在。在 MSA 上，550 很少是这个意思。RFC 6409 写明白了：MAIL FROM 的地址没有提交权限、或跟认证身份对不上，用 550 加 5.7.1；违反站点策略，用 550 加 5.7.0。

它说的是“你这个身份、或者这份内容，不被允许”

，卡在准入这一步，信压根没进传输。

所以看日志只看三位数字不够，得看增强状态码的第二段。5.1.x 是地址，5.2.x 是邮箱，5.3.x 是系统，5.7.x 是策略。分不清这个，排障会往反方向走：把策略拒绝当投递失败去查 DNS 和连接，能查一下午。

还有一件 MSA 故意不做的事：多数实现不会对收件人返回 5.1.1。返回了等于告诉提交者“你们公司有没有这个地址”，这是个目录枚举接口。它先收下，退信异步走。这是安全上的取舍，谈不上能力不够。

回头看，端口号只是表象，真正值得学的是它处理信任边界的方式：能靠端口分的，别靠参数分；能靠角色分的，别靠配置约定。

端口是硬的。连上 587 的那一刻，双方就知道这是提交会话，该认证、该限流、该改写。EHLO 是软的，能力靠协商，协商就可以不谈。SUBMITTER 死在软的那一层，MSA 活在硬的那一层。

这个判断在运维上还有一层后果。把提交和传递塞进同一个进程，短期省事，长期是把两个故障域焊在一起：线程池、队列、配置、限流全部共享，提交高峰会拖慢投递，25 端口被字典攻击打满连接，587 的用户跟着登不上。我遇到过一次，用户报的是“网页版发不了信”，最后查出来是 25 那边的连接数把进程撑满了。加机器没用，缺的是隔离。

再往上抬一点。今天做系统设计，把身份和权限的判断放到协议的第一跳，比放在业务层加校验更可靠。前者是结构，后者是纪律。纪律会被绕过，会被赶工期绕，会被“这个接口先上线”绕；结构绕不过去，不按结构走，连接根本建立不起来。

MSA 这套设计活了二十多年。RFC 写得漂亮这件事跟它活多久没关系——6409 读起来相当枯燥，一半篇幅在解释什么情况下可以用 554。真正管用的是它把“你是谁”这个问题，钉在了会话开始的那一刻。

邮件提交协议（MSA）：与标准 SMTP 有何不同？

测试

物联网

SMTP端口25与587的本质区别在于信任模型而非协议能力：25处理MTA间收信，587处理MUA提交且需认证。MSA角色定义、SUBMITTER扩展失败教训、465隐式TLS回归，均源于结构化的端口隔离优于协商机制。运维排障需区分5.7.x策略拒绝与投递失败，理解MIME膨胀、限流资源对象，实现安全高效的邮件系统。

服务器

热销域名限时优惠，新客首年免费！


domain

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

邮件提交协议（MSA）：与标准 SMTP 有何不同？

邮件提交协议（MSA）：与标准 SMTP 有何不同？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐