RFC 8689: Tùy chọn Yêu cầu TLS SMTP

Standards Track Transport Security Published March 2026

ELI5: Mã hóa email bình thường giống như yêu cầu một người chuyên chở "vui lòng sử dụng xe bọc thép nếu có sẵn." Nếu xe bọc thép đang bận, người chuyên chở chỉ cần lắc vai và dùng một chiếc xe thường. REQUIRETLS là một dấu hiệu trên phong bì nói rằng "xe bọc thép hoặc đừng giao nó cả." Thông điệp sẽ chứng tỏ được trả lại chứ không du hành mà không được mã hóa.

Tại Sao Điều Này Tồn Tại

Mã hóa email từ máy chủ này sang máy chủ khác (qua STARTTLS) là cơ hội theo mặc định. Nếu máy chủ nhận không hỗ trợ TLS, hoặc nếu một kẻ tấn công trung gian xóa khả năng STARTTLS, hầu hết các máy chủ gửi sẽ quay lại gửi dưới dạng văn bản rõ. Thư được gửi đi, nhưng không được mã hóa.

Các công nghệ như MTA-STS và DANE giải quyết vấn đề này ở cấp miền — chúng cho phép một miền nhận khai báo "tất cả thư gửi tới chúng tôi phải sử dụng TLS." Nhưng đó là các chính sách phía người nhận. Người gửi không có cách nào để nói "thư cụ thể này yêu cầu TLS ở mọi điểm chuyển."

RFC 8689 lấp đầy khoảng trống này bằng hai cơ chế bổ sung:

Tiện ích mở rộng SMTP REQUIRETLS: Một cờ cho mỗi thư trong phong bì SMTP cho biết mỗi máy chủ chuyển tiếp "không gửi thư này trừ khi điểm chuyển tiếp tiếp theo hỗ trợ TLS với chứng chỉ được xác minh."
Tiêu đề TLS-Required: Một tiêu đề thư có tín hiệu ý định tương tự, có thể sử dụng khi người gửi không có kiểm soát trực tiếp đối với phong bì SMTP (ví dụ: khi gửi qua MSA).

Cách Hoạt Động

Tiện Ích Mở Rộng SMTP REQUIRETLS

Người gửi quảng cáo ý định của mình trong quá trình giao dịch SMTP bằng cách thêm REQUIRETLS làm tham số cho lệnh MAIL FROM:

# Máy chủ quảng cáo hỗ trợ REQUIRETLS trong EHLO S: 220 mx.example.com ESMTP C: EHLO sender.example.org S: 250-mx.example.com S: 250-STARTTLS S: 250-REQUIRETLS S: 250 OK # Nâng cấp lên TLS trước C: STARTTLS S: 220 Go ahead # ... Bắt tay TLS với xác minh chứng chỉ ... C: EHLO sender.example.org S: 250-mx.example.com S: 250-REQUIRETLS S: 250 OK # Gửi với cờ REQUIRETLS C: MAIL FROM:<alice@example.org> REQUIRETLS S: 250 OK C: RCPT TO:<bob@example.com> S: 250 OK

Điều Gì Xảy Ra Ở Mỗi Điểm Chuyển

Khi máy chủ chuyển tiếp xử lý thư có cờ REQUIRETLS, nó phải thực thi các quy tắc sau trước khi chuyển tiếp:

TLS là bắt buộc. Kết nối với điểm chuyển tiếp tiếp theo phải sử dụng TLS. Nếu máy chủ tiếp theo không hỗ trợ STARTTLS, thư không được gửi — nó sẽ bị trả lại.
Xác minh chứng chỉ là bắt buộc. Chứng chỉ TLS của điểm chuyển tiếp tiếp theo phải hợp lệ và khớp với tên máy chủ (thông qua DANE/TLSA hoặc Web PKI). Chứng chỉ tự ký hoặc không khớp sẽ gây trả lại.
Cờ REQUIRETLS lan tỏa. Máy chủ chuyển tiếp phải chuyển tham số REQUIRETLS đến điểm chuyển tiếp tiếp theo nếu nó cũng hỗ trợ tiện ích mở rộng. Nếu điểm chuyển tiếp tiếp theo không hỗ trợ REQUIRETLS, máy chủ chuyển tiếp vẫn có thể gửi nếu nó có thể xác minh TLS thông qua DANE hoặc MTA-STS.

Tiêu Đề TLS-Required

Đối với những người gửi gửi qua MSA và không kiểm soát trực tiếp các tham số SMTP, tiêu đề TLS-Required cung cấp tín hiệu tương tự:

TLS-Required: No ; Chờ — "No" có nghĩa là "không yêu cầu TLS"? ; Đúng. Tiêu đề có hai giá trị: ; TLS-Required: No → rõ ràng từ chối REQUIRETLS ; (sử dụng TLS cơ hội bình thường) ; Sự vắng mặt của tiêu đề có nghĩa là hành vi bình thường. ; Cờ phong bì REQUIRETLS là tín hiệu tích cực.

Tiêu đề TLS-Required: No được thiết kế đặc biệt như một cơ chế từ chối. Nó cho MTA gửi biết: "ngay cả khi REQUIRETLS sẽ thường áp dụng cho thư này (ví dụ: vì chính sách toàn miền), đừng thực thi nó cho thư cụ thể này." Điều này hữu ích cho các thư như đặt lại mật khẩu hoặc thông báo nơi gửi quan trọng hơn mã hóa được đảm bảo.

Hành Vi Trả Lại

Khi REQUIRETLS ngăn chặn gửi, máy chủ gửi tạo báo cáo không gửi được (trả lại). Chính phần trả lại này cũng phải được gửi qua TLS — REQUIRETLS áp dụng cho các thư DSN (Thông báo Trạng thái Gửi) cũng. Nếu phần trả lại không thể được gửi an toàn, nó sẽ bị loại bỏ im lặng thay vì được gửi dưới dạng văn bản rõ (để tránh rò rỉ thông tin về thư ban đầu).

# Điểm chuyển tiếp tiếp theo không hỗ trợ TLS — REQUIRETLS ngăn chặn gửi C: EHLO relay.example.org S: 250-mx.recipient.com S: 250 OK # Không quảng cáo STARTTLS — không thể gửi với REQUIRETLS # Máy chủ chuyển tiếp tạo phần trả lại cho alice@example.org: # 550 5.7.30 Hỗ trợ REQUIRETLS bắt buộc nhưng không có sẵn

Chi Tiết Kỹ Thuật Chính

Mối Quan Hệ Với MTA-STS Và DANE

Cơ Chế	Ai Đặt Chính Sách	Phạm Vi	Phương Pháp Xác Minh
MTA-STS	Miền nhận	Tất cả thư tới miền	Web PKI (tìm nạp HTTPS)
DANE	Miền nhận	Tất cả thư tới miền	DNSSEC + bản ghi TLSA
REQUIRETLS	Máy chủ/người gửi	Cho mỗi thư	DANE hoặc MTA-STS ở mỗi điểm chuyển

REQUIRETLS là bổ sung, không cạnh tranh. MTA-STS và DANE bảo vệ thư gửi đến của miền nhận. REQUIRETLS bảo vệ một thư gửi đi cụ thể. Một thư có REQUIRETLS được xác minh bằng DANE hoặc MTA-STS ở mỗi điểm chuyển — nếu không có cái nào có sẵn cho một điểm chuyển, gửi sẽ thất bại.

Yêu Cầu Phiên Bản TLS

REQUIRETLS yêu cầu TLS 1.2 trở lên. Các kết nối sử dụng TLS 1.0 hoặc 1.1 không đáp ứng yêu cầu, phù hợp với RFC 8996 phản đối các phiên bản TLS cũ hơn.

Mã Trạng Thái Nâng Cao

Mã	Ý Nghĩa
`5.7.30`	Hỗ trợ REQUIRETLS bắt buộc nhưng không có sẵn ở điểm chuyển tiếp tiếp theo
`5.7.31`	Không thể thực hiện REQUIRETLS (ví dụ: chứng chỉ của điểm chuyển tiếp tiếp theo không hợp lệ)

Những Sai Lầm Thường Gặp

Giả định REQUIRETLS được triển khai rộng rãi. Sự áp dụng vẫn còn hạn chế. Hầu hết các MTA không hỗ trợ tiện ích mở rộng REQUIRETLS. Sử dụng nó cho tất cả thư sẽ dẫn đến trả lại cho nhiều người nhận.
Nhầm lẫn REQUIRETLS với STARTTLS. STARTTLS là cơ chế để nâng cấp kết nối lên TLS. REQUIRETLS là chính sách bắt buộc STARTTLS thành công và chứng chỉ xác minh. STARTTLS mà không có REQUIRETLS là cơ hội; REQUIRETLS làm cho nó bắt buộc.
Mong đợi mã hóa từ đầu đến cuối. REQUIRETLS đảm bảo TLS ở mỗi điểm chuyển, nhưng thư được giải mã và mã hóa lại ở mỗi máy chủ chuyển tiếp. Nó là mã hóa từ điểm này sang điểm khác, không phải từ đầu đến cuối. Để có mã hóa từ đầu đến cuối thực sự, hãy sử dụng S/MIME hoặc PGP.
Không xử lý phần trả lại. REQUIRETLS sẽ gây ra lỗi gửi hợp pháp khi máy chủ của người nhận không hỗ trợ TLS hoặc có vấn đề chứng chỉ. Ứng dụng của bạn phải xử lý các phần trả lại này và có khả năng thử lại mà không có REQUIRETLS hoặc thông báo cho người dùng.
Sử dụng TLS-Required: Yes. Không có giá trị TLS-Required: Yes. Tiêu đề chỉ có giá trị No để từ chối. Tín hiệu tích cực là tham số SMTP REQUIRETLS, không phải giá trị tiêu đề.
Quên về phần trả lại. REQUIRETLS áp dụng cho các thư DSN cũng. Nếu phần trả lại không thể được gửi qua TLS, nó sẽ bị loại bỏ im lặng. Người gửi gốc có thể không bao giờ biết gửi không thành công.

Ảnh Hưởng Đến Khả Năng Gửi

Giảm tỷ lệ gửi. Bật REQUIRETLS cho tất cả thư sẽ gây ra lỗi gửi cho các máy chủ không hỗ trợ TLS hoặc có vấn đề chứng chỉ. Sử dụng nó có chọn lọc cho các thư nơi bảo mật vượt quá sự chắc chắn gửi.
Bảo vệ các thư giá trị cao. Đối với các thông báo tài chính, tài liệu pháp lý, dữ liệu chăm sóc sức khỏe, hoặc bất kỳ thư nào phải tuân thủ quy định, REQUIRETLS đảm bảo thư không bao giờ được truyền dưới dạng văn bản rõ.
Bổ sung MTA-STS. Nếu miền của bạn xuất bản MTA-STS và các miền của người nhận cũng có MTA-STS hoặc DANE, REQUIRETLS thêm sự đảm bảo cho mỗi thư trên các chính sách cấp miền. Sự kết hợp cung cấp bảo mật vận chuyển mạnh nhất có sẵn trong SMTP.
Các thư trả lại cũng được bảo vệ. Vì REQUIRETLS áp dụng cho các DSN, thông tin nhạy cảm trong các thư trả lại (có thể bao gồm các phần của thư ban đầu) cũng được bảo vệ khỏi truyền dưới dạng văn bản rõ.