SMTP 25 与 465 到底有什么区别？

发表于 2026/09/04 更新于 2026/09/04

作者 Luka Chia

13 分钟阅读

从 TCP、DNS、SMTP、TLS 到 Firewall Domain Filtering

1. 问题背景

在企业网络环境中，一个很常见的需求是：

允许应用服务器向指定的邮件服务器发送邮件，同时限制应用只能访问指定的邮件域名。

例如：

Application
     |
     | SMTP
     v
Network Firewall
     |
     v
Mail Server

如果防火墙策略要求只允许：

smtp.example.com

那么一个关键问题就出现了：

Firewall 到底通过什么信息判断客户端正在访问哪个邮件域名？

要回答这个问题，需要把 DNS、TCP、SMTP、TLS 和 Firewall 放在同一个连接过程中理解。

2. 先区分 URL、Domain 和 IP

在讨论 Firewall Filtering 时，首先要把几个概念区分开。

例如：

https://mail.example.com/path

这是一个 URL。

其中：

mail.example.com

是 Domain / Hostname。

而 DNS 解析后可能得到：

mail.example.com
        |
        v
203.0.113.10

这是 IP Address。

SMTP 通信通常不会像 HTTP 那样携带完整的 URL。对于邮件服务器连接，我们更多关注的是：

SMTP Server hostname / FQDN
Destination IP
Destination Port
TLS SNI
SMTP application-layer information

因此，讨论 SMTP Firewall Filtering 时，更准确的说法应该是：

Domain / FQDN Filtering，而不是 URL Path Filtering。

3. DNS 发生在 TCP 连接之前

假设应用配置：

smtp.example.com

在建立 SMTP TCP 连接之前，客户端通常需要先解析这个名称：

Application
     |
     | DNS Query
     v
DNS Server
     |
     | 203.0.113.10
     v
Application

因此：

smtp.example.com
        |
        v
203.0.113.10

已经完成了从 Domain 到 IP 的映射。

这里有一个非常重要的区别：

DNS 负责把 Domain 解析成 IP；TCP 连接本身使用的是 IP + Port。

因此，当客户端真正建立 TCP 连接时：

TCP SYN
Source: Client IP
Destination: 203.0.113.10:25

TCP Header 中并没有：

smtp.example.com

这个字段。

4. SMTP 25：传统 SMTP + STARTTLS

25 端口主要用于 SMTP Server-to-Server / Relay 场景。

一个典型的 SMTP 连接过程可能是：

Client                         SMTP Server
  |                                |
  |-------- TCP SYN -------------->|
  |<------- TCP SYN/ACK -----------|
  |-------- TCP ACK -------------->|
  |                                |
  |<------- 220 ESMTP -------------|
  |-------- EHLO client.example -->|
  |<------- 250-STARTTLS ----------|
  |                                |
  |-------- STARTTLS -------------->|
  |<------- 220 Ready -------------|
  |                                |
  |<======= TLS Handshake =========>|
  |                                |
  |<======= Encrypted SMTP ========>|

这里最重要的是：

SMTP plaintext
      |
      | STARTTLS
      v
TLS
      |
      v
Encrypted SMTP

在 STARTTLS 之前，SMTP 应用层数据可能是明文的。

例如：

EHLO client.example.com

以及 SMTP 协商过程中的其他命令，在没有进入 TLS 之前可能可以被路径中的流量检查设备看到。

因此，对于 25 端口：

不能简单说”25 端口没有 Domain”。

更准确的说法是：

TCP 建连阶段使用的是 Destination IP + Port；
Domain 可能已经在 DNS 查询阶段出现；
STARTTLS 之前，SMTP 应用层存在可观察的明文协议数据；
STARTTLS 之后，SMTP 数据进入 TLS 加密状态。

5. SMTP 465：Implicit TLS

465 的工作方式与 STARTTLS 不同。

RFC 8314 将 465 定义为基于 TLS 的 SMTP Submission，也就是：

TCP 连接建立后立即进行 TLS。

连接过程可以抽象成：

Client                         SMTP Server
  |                                |
  |-------- TCP SYN -------------->|
  |<------- TCP SYN/ACK -----------|
  |-------- TCP ACK -------------->|
  |                                |
  |======= TLS ClientHello =======>|
  |<====== TLS ServerHello ========|
  |                                |
  |<======= TLS Handshake =========>|
  |                                |
  |<======= Encrypted SMTP =======>|

因此 465 更准确的抽象是：

TCP
 ↓
TLS
 ↓
SMTP

而不是：

TCP
 ↓
SMTP plaintext
 ↓
STARTTLS
 ↓
TLS

这也是 25 + STARTTLS 与 465 + Implicit TLS 最核心的区别之一。

6. 465 中的 SNI

TLS ClientHello 中可能包含：

Server Name Indication (SNI)

例如：

TLS ClientHello

SNI:
smtp.example.com

因此，在客户端发送 SNI、且没有其他机制隐藏该信息的情况下，具备 TLS/SNI 识别能力的中间设备可能利用 SNI 获取目标 hostname。

所以 465 的信息来源可以理解为：

DNS
  |
  +---- smtp.example.com
  |
  v
203.0.113.10
  |
  +---- TCP:465
  |
  v
TLS ClientHello
  |
  +---- SNI: smtp.example.com

但是需要特别注意：

不能把”SNI 存在”理解成”所有 465 连接一定都能被 Firewall 通过 SNI 识别”。

是否存在 SNI、设备是否检查 SNI、设备是否支持对应协议，以及是否存在 ECH 等因素，都可能影响最终结果。

7. Firewall 到底能看到什么？

可以从不同阶段理解。

7.1 DNS 层

如果 Firewall 能够观察 DNS 流量，它可能看到：

Query:
smtp.example.com

但这并不意味着该 DNS 查询一定能够与后续 TCP 会话可靠地一一对应。

客户端可能使用：

DNS Cache
DoH
DoT
其他 DNS resolver

因此不能仅依赖 DNS 判断最终网络连接。

7.2 IP / TCP 层

Firewall 一定可以从正常的 L3/L4 流量中获得类似：

Source IP
Destination IP
Protocol
Destination Port

例如：

10.0.1.10
    |
    | TCP
    v
203.0.113.10:465

但这里仍然没有直接携带：

smtp.example.com

7.3 SMTP 明文阶段

对于 25 + STARTTLS：

SMTP
 ↓
EHLO
 ↓
STARTTLS
 ↓
TLS

在进入 TLS 之前，具备相应应用层检测能力的设备可能观察到 SMTP 明文。

7.4 TLS ClientHello

对于 465：

TCP
 ↓
TLS ClientHello
 ↓
SNI

如果 ClientHello 中存在明文 SNI，支持 TLS/SNI 检查的设备可能利用这个信息进行策略判断。

8. 25 与 465 的核心对比

项目 SMTP 25 SMTP 465 ———————– ———————– ———————— TCP 目标端口 25 465

典型用途 Server-to-Server / SMTP Submission over TLS Relay

TCP 建立是是

初始应用协议 SMTP TLS

TLS 模式通常 STARTTLS Implicit TLS

TLS 开始时间 SMTP 协商后 TCP 建立后立即开始

STARTTLS 可以使用不采用这种模式

SMTP 初始明文可能存在没有 SMTP 明文阶段

TLS ClientHello STARTTLS 后建连后立即出现

SNI 取决于 TLS/客户端取决于 TLS/客户端

Firewall 可观察信息 IP、Port、DNS、SMTP IP、Port、DNS、TLS/SNI 明文、TLS 等等

是否能通过 Domain 过滤取决于 Firewall 取决于 Firewall 的检测能力和策略的检测能力和策略 ————————————————————————

9. 一个容易产生误解的地方：Domain 不等于 TCP Destination

假设：

smtp.example.com
        |
        v
203.0.113.10

客户端最终建立：

TCP → 203.0.113.10:465

那么从 TCP 层面看，连接目标是：

203.0.113.10:465

而：

smtp.example.com

是这个 IP 所对应的 hostname。

因此：

Domain 是应用、DNS 或 TLS 等更高层信息中的概念，而不是 TCP Header 中的字段。

这也是为什么”基于 Domain 的 Firewall Filtering”本质上不是简单的 L3/L4 IP + Port Filtering。

10. OCI Network Firewall 中应该如何理解？

OCI Network Firewall 提供 Stateful Network Filtering、Custom URL and FQDN Filtering、SSL Inspection 等能力。

因此，在 OCI 环境中需要把几个概念区分开：

L3/L4 Filtering
    |
    +---- Source IP
    +---- Destination IP
    +---- Port
    +---- Protocol

FQDN / URL Filtering
    |
    +---- Domain / URL related identification

SSL Inspection
    |
    +---- Decrypt
    +---- Inspect
    +---- Re-encrypt

OCI 官方文档说明 Network Firewall 支持 Custom URL and FQDN Filtering，也支持 TLS/SSL inspection。具体规则是否能够对某一种 SMTP 流量通过 SNI、应用识别或解密后的内容进行匹配，需要结合具体协议、Firewall policy、decryption 配置和产品支持情况进行验证。

因此，不应该简单得出：

“OCI Network Firewall 看到 465 的 SNI，所以 URL List 一定可以直接按照 SMTP 465 的 SNI 做匹配。”

更严谨的工程结论应该是：

Firewall 能够获得某个 hostname，并不自动意味着该 hostname 一定可以被某一种具体的 URL/FQDN Policy 用于匹配。最终行为需要以该 Firewall 产品对对应协议和策略类型的支持为准。

11. 如果目标是”只允许指定邮件服务器”，应该怎么设计？

例如应用只允许：

smtp.example.com

可以从多个维度建立控制：

                Application
                     |
                     |
                     v
             Network Firewall
                     |
        +------------+------------+
        |                         |
        v                         v
   L3/L4 Policy              FQDN / URL
        |                         |
 Destination IP              Domain Policy
 Port 25 / 465
        |                         |
        +------------+------------+
                     |
                     v
                Mail Server

如果安全要求较高，还需要进一步考虑：

DNS 是否可信；
SMTP Server 是否使用稳定的 IP；
Domain 是否存在多个 IP；
TLS/SNI 是否存在；
是否需要 TLS inspection；
Firewall 是否支持该 SMTP 场景的 FQDN 识别；
是否需要同时限制 IP + Port；
是否需要记录 Firewall Logs 进行验证。

12. Troubleshooting：遇到问题应该怎么查？

当应用无法连接 SMTP Server 时，可以按照下面的顺序排查。

Step 1：DNS

nslookup smtp.example.com

确认：

smtp.example.com
        ↓
IP address

Step 2：TCP

测试：

nc -vz smtp.example.com 25

或者：

nc -vz smtp.example.com 465

确认 TCP 是否可以建立。

Step 3：25 端口

如果使用 STARTTLS，可以进一步测试 SMTP/TLS 协商。

例如：

openssl s_client -starttls smtp -connect smtp.example.com:25

观察：

SMTP Banner
STARTTLS
TLS handshake
Certificate
SNI / Server Name

Step 4：465 端口

可以使用：

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com

观察：

TLS handshake
Certificate
SNI
TLS version
Cipher

Step 5：Firewall

最终结合 Firewall Logs 判断：

Source
Destination
Port
Application
Policy
Action
TLS / Decryption

这样才能判断：

到底是网络层被拒绝，还是 Firewall Policy 没有匹配，还是 TLS/SMTP 协商失败。

13. 最终结论

SMTP 25 与 465 最大的区别，不是：

一个有 Domain，一个没有 Domain。

而是：

TLS 在 SMTP 通信中的位置不同。

Port 25 + STARTTLS

DNS
 ↓
TCP:25
 ↓
SMTP
 ↓
STARTTLS
 ↓
TLS
 ↓
Encrypted SMTP

Port 465 + Implicit TLS

DNS
 ↓
TCP:465
 ↓
TLS
 ↓
Encrypted SMTP

因此，在讨论 Firewall Domain Filtering 时，应该从多个信息源理解 Domain：

                 Domain / FQDN
                      |
       +--------------+--------------+
       |              |              |
       v              v              v
      DNS            SNI       SMTP/Application
       |              |              |
       +--------------+--------------+
                      |
                      v
                   Firewall
                      |
                      v
                  Policy Match

最终需要记住一句话：

TCP 连接知道的是 IP + Port；Domain 需要通过 DNS、TLS/SNI 或应用层协议等其他信息获得。

而 Firewall 能否利用这些信息完成 Domain/FQDN Filtering，则取决于具体 Firewall 产品的协议识别、策略类型以及是否启用了相应的检查能力。

14. References

RFC 8314 — Cleartext Considered Obsolete: Use of TLS for Email Submission and Access
Oracle Cloud Infrastructure Network Firewall Documentation
Oracle Cloud Infrastructure Network Firewall — URL/FQDN Filtering
Oracle Cloud Infrastructure Network Firewall — SSL/TLS Inspection

Networking

本文由作者按照 CC BY 4.0 进行授权