RFC 6409 – Gửi Tin nhắn cho Thư điện tử

Internet Standard Core SMTP & Message Format Obsoletes RFC 4409 Published March 2026

ELI5: Hãy tưởng tượng sự khác biệt giữa thả một lá thư vào hộp thư công cộng trên đường phố và đưa nó cho nhân viên tại quầy bưu điện. Hộp thư đường phố (cổng 25) dành cho những người chuyển phát thư giữa các bưu điện. Quầy bưu điện (cổng 587) là nơi bạn, với tư cách khách hàng, nộp lá thư của mình — bạn phải xuất trình giấy tờ tùy thân trước, và nhân viên sẽ kiểm tra mọi thứ có đúng thứ tự hay không. RFC 6409 định nghĩa quầy bưu điện đó cho email.

Tại sao RFC này tồn tại

Vào những ngày đầu của email, không có sự phân biệt giữa một người dùng gửi tin nhắn mới và một máy chủ chuyển tiếp thư từ máy chủ khác. Cả hai đều sử dụng cổng 25 và bất kỳ ai cũng có thể kết nối và gửi. Điều này dẫn đến vấn đề relay mở — những kẻ gửi thư rác khai thác bất kỳ máy chủ nào chấp nhận và chuyển tiếp thư mà không cần xác thực.

RFC 6409 (ban đầu là RFC 2476 năm 1998, cập nhật thành RFC 4409 năm 2006, và hoàn thiện thành 6409 năm 2011) chính thức tách biệt gửi thư khỏi chuyển tiếp thư:

Gửi thư (cổng 587): Một người dùng hoặc ứng dụng được xác thực gửi một thư mới cho dịch vụ thư của họ để gửi đi. Máy chủ hoạt động như một MSA (RFC 5598).
Chuyển tiếp (cổng 25): Một máy chủ thư chuyển một thư sang máy chủ thư khác trên đường tới đích. Máy chủ hoạt động như một MTA.

Sự tách biệt này là nền tảng của bảo mật email hiện đại. Nó cho phép xác thực của người gửi, thực thi chính sách, và khả năng chặn chuyển tiếp không xác thực trong khi vẫn chấp nhận các gửi thư hợp pháp.

Nó hoạt động như thế nào

Gửi thư sử dụng cùng giao thức SMTP được định nghĩa trong RFC 5321, nhưng có những khác biệt quan trọng về hành vi, chính sách và số cổng.

Quy trình gửi thư

Khách hàng (MUA hoặc ứng dụng) kết nối với MSA trên cổng 587.
Khách hàng phát hành EHLO và khám phá các tiện ích khả dụng.
Khách hàng nâng cấp lên TLS bằng STARTTLS (hoặc kết nối qua TLS ngầm trên cổng 465 theo RFC 8314).
Khách hàng xác thực bằng AUTH (RFC 4954) — thường là PLAIN hoặc LOGIN qua TLS.
Khách hàng gửi thư bằng MAIL FROM, RCPT TO, và DATA.
MSA xác thực thư, có thể thêm các tiêu đề bị thiếu (Date, Message-ID), và xếp hàng cho gửi đi qua cơ sở hạ tầng MTA.

Gửi thư so với Chuyển tiếp: Cạnh nhau

Khía cạnh	Gửi thư (MSA, cổng 587)	Chuyển tiếp (MTA, cổng 25)
Mục đích	Chấp nhận thư mới từ người dùng/ứng dụng	Chuyển thư giữa các máy chủ
Xác thực	Bắt buộc (SMTP AUTH)	Không bắt buộc (tin tưởng giữa các máy chủ)
Mã hóa	Bắt buộc (STARTTLS hoặc TLS ngầm)	Cơ hội (STARTTLS khi có sẵn)
Xác thực người gửi	MSA kiểm tra rằng người dùng được xác thực được phép sử dụng địa chỉ From	MTA kiểm tra SPF, DKIM, DMARC
Sửa chữa tiêu đề	MSA có thể thêm các tiêu đề Date, Message-ID và MIME bị thiếu	MTA chỉ thêm tiêu đề Received
Ai kết nối	Người dùng cuối, ứng dụng, dịch vụ email	Các máy chủ thư khác

Ví dụ SMTP

Một phiên gửi thư điển hình trên cổng 587:

# Khách hàng kết nối tới cổng 587 S: 220 smtp.mailertogo.com ESMTP Submission C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-STARTTLS S: 250-AUTH PLAIN LOGIN S: 250-SIZE 26214400 S: 250-8BITMIME S: 250 ENHANCEDSTATUSCODES # Nâng cấp lên TLS trước C: STARTTLS S: 220 2.0.0 Ready to start TLS # Bắt tay TLS diễn ra ở đây, sau đó re-EHLO C: EHLO app.example.com S: 250-smtp.mailertogo.com S: 250-AUTH PLAIN LOGIN S: 250-SIZE 26214400 S: 250-8BITMIME S: 250 ENHANCEDSTATUSCODES # Xác thực (thông tin đăng nhập được mã hóa Base64) C: AUTH PLAIN AGFsaWNlQGV4YW1wbGUuY29tAHNlY3JldA== S: 235 2.7.0 Authentication successful # Bây giờ gửi thư C: MAIL FROM:<notifications@example.com> S: 250 2.1.0 OK C: RCPT TO:<user@recipient.com> S: 250 2.1.5 OK C: DATA S: 354 Start mail input C: From: Example App <notifications@example.com> C: To: user@recipient.com C: Subject: Your order has shipped C: Date: Wed, 11 Mar 2026 14:00:00 +0000 C: Message-ID: <order-12345@example.com> C: C: Your order #12345 has been shipped and is on its way. C: . S: 250 2.0.0 OK, queued as abc123 C: QUIT S: 221 2.0.0 Bye

Chi tiết kỹ thuật chính

Xác thực là bắt buộc

RFC 6409 nêu rõ rằng MSA SHOULD yêu cầu xác thực và MUST NOT chấp nhận thư để chuyển tiếp từ các khách hàng không xác thực trừ khi có chính sách tổ chức cụ thể cho phép. Trong thực tế, mọi máy chủ gửi thư hiện đại đều yêu cầu xác thực. Cơ chế tiêu chuẩn là SMTP AUTH (RFC 4954) sử dụng các cơ chế PLAIN hoặc LOGIN, luôn qua TLS.

Sửa chữa tiêu đề bởi MSA

Không giống như MTA (phải không thay đổi nội dung thư), MSA được kỳ vọng sẽ kiểm tra và sửa chữa thư được gửi:

Thêm tiêu đề Date bị thiếu nếu khách hàng không thêm.
Thêm Message-ID bị thiếu để đảm bảo mỗi thư có một định danh duy nhất.
Xác thực địa chỉ From khớp với định danh được xác thực, hoặc thêm tiêu đề Sender: để chỉ ra thực thể truyền tải thực.
Thêm tiêu đề dấu vết — MSA thêm tiêu đề Received: của riêng nó như mục nhập đầu tiên.

Cổng 465: TLS ngầm

Về mặt lịch sử, cổng 465 được gán một lần ngắn cho "SMTPS" (SMTP qua TLS ngầm), sau đó được gán lại, rồi được chuẩn hóa lại bởi RFC 8314 năm 2018. Ngày nay, cổng 465 với TLS ngầm là cách tiếp cận được đề xuất cho gửi thư — bắt tay TLS diễn ra ngay khi kết nối, trước bất kỳ lệnh SMTP nào. Cổng 587 với STARTTLS vẫn được hỗ trợ rộng rãi và hợp lệ.

Giới hạn kích thước và tốc độ

MSA thường thực thi các giới hạn nghiêm ngặt hơn MTA:

Giới hạn kích thước thư (thường 10-25 MB)
Giới hạn tốc độ cho mỗi người dùng được xác thực (để ngăn chặn các tài khoản bị xâm phạm gửi thư rác)
Giới hạn số người nhận cho mỗi thư và mỗi khoảng thời gian
Hạn chế địa chỉ người gửi (bạn chỉ có thể gửi từ các địa chỉ bạn được phép sử dụng)

Những sai lầm phổ biến

Gửi trên cổng 25 từ một ứng dụng. Các ứng dụng luôn nên gửi qua cổng 587 (hoặc 465) với xác thực. Gửi trực tiếp tới MX của người nhận trên cổng 25 bỏ qua xác thực của dịch vụ email của bạn, ký DKIM và quản lý danh tiếng. Hầu hết các nền tảng đám mây (AWS, GCP, Azure) chặn cổng 25 gửi đi theo mặc định.
Không sử dụng TLS trước AUTH. Gửi thông tin xác thực qua kết nối không mã hóa sẽ tiết lộ tên người dùng và mật khẩu SMTP của bạn. Luôn STARTTLS trước AUTH, hoặc sử dụng TLS ngầm trên cổng 465.
Nhầm lẫn thông tin đăng nhập gửi thư với thông tin đăng nhập hộp thư. Một số dịch vụ sử dụng thông tin đăng nhập riêng biệt cho gửi thư SMTP so với truy cập IMAP/POP. Kiểm tra tài liệu của nhà cung cấp của bạn.
Bỏ qua các phản hồi từ chối MSA. Nếu MSA từ chối thư của bạn (ví dụ: địa chỉ người gửi không được phép, thư quá lớn), ứng dụng của bạn cần xử lý điều này một cách khéo léo, không bỏ qua lỗi.
Mã hóa cứng cổng 25 trong mã ứng dụng. Các ứng dụng cũ kết nối tới cổng 25 để gửi thư gây ra các vấn đề về khả năng gửi và có thể ngừng hoạt động hoàn toàn khi các ISP và nhà cung cấp đám mây ngày càng chặn cổng này cho việc không phải máy chủ.
Không phát hành lại EHLO sau STARTTLS. Sau khi bắt tay TLS hoàn tất, bạn phải gửi EHLO mới. Danh sách khả năng của máy chủ có thể thay đổi (AUTH thường chỉ được quảng cáo sau khi mã hóa được thiết lập).

Tác động khả năng gửi

Xác thực cho phép ký DKIM. Khi bạn gửi qua MSA, dịch vụ có thể áp dụng chữ ký DKIM cho thư của bạn. Gửi trực tiếp tới MTA từ xa bỏ qua điều này, có nghĩa là thư của bạn đến không có chữ ký và có khả năng bị đánh dấu là thư rác.
Xác thực danh tính người gửi. MSA xác thực rằng bạn được phép gửi từ địa chỉ bạn tuyên bố. Điều này ngăn chặn tài khoản của bạn bị sử dụng để giả mạo các miền khác và duy trì danh tiếng gửi của bạn.
Quản lý danh tiếng. Dịch vụ email của bạn (MSA) duy trì danh tiếng IP được chia sẻ. Bằng cách định tuyến qua gửi thư, thư của bạn được hưởng lợi từ danh tiếng được thiết lập của dịch vụ với các nhà cung cấp hộp thư lớn.
Xử lý vòng lặp phản hồi. MSA xử lý thư của bạn có thể theo dõi các cuộc gọi lại, than phiền và trạng thái gửi, cung cấp dữ liệu bạn cần để duy trì vệ sinh danh sách và bảo vệ danh tiếng gửi của bạn.
TLS ở mọi nơi. Gửi qua TLS (bắt buộc để gửi thư) đảm bảo thư của bạn được mã hóa từ ứng dụng của bạn tới dịch vụ email. Dịch vụ sau đó xử lý mã hóa cho lần tiếp theo, cung cấp cho bạn bảo vệ end-to-end trong quá trình vận chuyển.