嘿，这个问题问到点子上了！核心原因在于这两个配置对应的服务定位、安全需求完全不一样，我给你拆解开说：

1. 服务的定位天差地别 #

• main.cf里的规则是给25端口的默认SMTP服务用的：这个端口是Postfix用来接收其他邮件服务器发来邮件的（就是你的域名MX记录指向的服务）。它需要对整个公网的合法邮件服务器开放，如果这里用reject结尾，会把所有没通过前面限制的连接直接拒掉——但绝大多数正常的外部邮件服务器根本不在你的白名单里，这样你就收不到朋友、公司发来的邮件了！所以main.cf里的smtpd_client_restrictions通常以permit结尾，或者依赖Postfix默认的“允许所有未被明确拒绝的连接”策略，保证能接收合法的外部邮件。
• master.cf里的submission服务是给587端口用的：这个端口专门给用户客户端（比如Thunderbird、Outlook或者手机邮箱APP）发邮件用的，核心要求是用户必须先认证（通常会配smtpd_sasl_auth_enable = yes）。这里用reject结尾是为了兜底：只有通过前面规则（比如已认证、来自可信IP）的连接才能放行，其他所有请求一律拒绝——毕竟我们只信任自己的用户通过这个端口发邮件，绝对不能让陌生人随便用这个端口发垃圾邮件。

2. 默认策略链的差异 #

Postfix的限制规则是按顺序执行的，匹配到第一条符合的规则就停止。

• 对于25端口的默认SMTP服务，Postfix的默认兜底策略是允许所有连接，所以哪怕你在main.cf里没写permit，最后也会默认放行。
• 而submission服务是在master.cf里单独配置的“自定义服务”，它的默认策略更严格，或者管理员会刻意设置成“拒绝所有未被明确允许的连接”，所以必须明确加上reject来兜底，确保没有通过前面限制的请求都被挡在外面。

3. 安全模型的区别 #

• 25端口是面向公网的“邮件交换入口”，必须平衡兼容性和安全性：只能做一些基础的反垃圾限制（比如拒绝黑名单IP），但不能太苛刻，否则会误杀合法邮件。
• 587端口是面向内部用户的“发件入口”，安全优先级远高于兼容性：必须确保只有经过认证的可信用户才能使用，所以规则链最后用reject把所有不符合条件的请求都拒掉，彻底杜绝滥用风险。

举个直观的例子：
submission服务的典型配置：

submission inet n       -       y       -       -       smtpd
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject

意思很明确：只允许已经认证的用户，其他全部拒绝。

main.cf里的典型配置：

smtpd_client_restrictions = permit_mynetworks, reject_rbl_client zen.spamhaus.org, permit

逻辑是：允许内网机器，拒绝Spamhaus黑名单里的垃圾IP，其他所有合法邮件服务器都放行。

内容的提问来源于stack exchange，提问作者TCB13