RFC 5321 – Giao thức truyền thư đơn giản

Current Standard Core SMTP & Message Format Obsoletes RFC 2821 Published March 2026

ELI5: SMTP là dịch vụ bưu chính của Internet. Khi bạn gửi một email, máy chủ thư của bạn mở một cuộc hội thoại với máy chủ thư của người nhận, giới thiệu chính nó, nói rõ ai là người gửi thư và ai là người nhận, sau đó giao bức thư. Máy chủ nhận hoặc chấp nhận nó, nói "hãy thử lại sau," hoặc từ chối hoàn toàn. Mọi email bạn từng gửi đã đi qua SMTP.

Tại Sao RFC Này Tồn Tại

SMTP là giao thức lâu đời nhất và cơ bản nhất cung cấp năng lượng cho email. Dòng dõi của nó kéo dài trở lại RFC 821, được xuất bản năm 1982 bởi Jon Postel. RFC 5321, xuất bản năm 2008, là đặc tả định nghĩa hiện tại. Nó hợp nhất hàng thập kỷ mở rộng, làm rõ và kinh nghiệm hoạt động thành một tài liệu có thẩm quyền duy nhất.

Sự phát triển chính từ RFC 821 đến 5321 bao gồm: chính thức hóa ESMTP (Extended SMTP), làm rõ hành vi chuyển tiếp so với gửi, yêu cầu nghiêm ngặt hơn xung quanh tra cứu MX DNS, quy tắc cập nhật cho chữ địa chỉ và IPv6, và yêu cầu xử lý phản hồi. RFC này là nền tảng mà mọi RFC email khác được xây dựng dựa vào.

Nó Hoạt Động Như Thế Nào

Một giao dịch SMTP là một cuộc hội thoại có cấu trúc giữa hai máy chủ trên kết nối TCP (thường là cổng 25). Giao thức dựa trên văn bản và hướng dòng — mọi lệnh và phản hồi đều là ASCII có thể đọc được của con người.

Mô Hình SMTP

SMTP định nghĩa ba vai trò:

SMTP Client (Sender-SMTP): Hệ thống bắt đầu kết nối để chuyển giao một thông báo.
SMTP Server (Receiver-SMTP): Hệ thống chấp nhận kết nối và nhận thông báo.
SMTP Relay: Một máy chủ nhận một thông báo và chuyển tiếp nó hướng đến điểm đến cuối cùng của nó, hoạt động như cả máy khách và máy chủ.

Máy khách kết nối, xác định chính nó bằng EHLO, chỉ định người gửi envelope (MAIL FROM), một hoặc nhiều người nhận (RCPT TO), rồi truyền dữ liệu thông báo (DATA). Máy chủ phản hồi mỗi lệnh bằng mã trạng thái ba chữ số.

Các Lệnh SMTP

Lệnh	Mục Đích
`EHLO`	Xác định máy khách và yêu cầu các tính năng mở rộng. Thay thế `HELO` cũ hơn.
`MAIL FROM:<addr>`	Chỉ định người gửi envelope (return-path cho các phản hồi).
`RCPT TO:<addr>`	Chỉ định một người nhận. Được phát hành một lần cho mỗi người nhận.
`DATA`	Bắt đầu truyền nội dung thông báo. Kết thúc bằng một `.` đơn lẻ trên một dòng.
`RSET`	Hủy bỏ giao dịch hiện tại và đặt lại trạng thái.
`VRFY`	Xác minh người dùng tồn tại (hiếm khi được hỗ trợ do lạm dụng).
`EXPN`	Mở rộng danh sách gửi thư (hiếm khi được hỗ trợ).
`NOOP`	Không có thao tác; giữ kết nối sống.
`QUIT`	Đóng kết nối.

Mã Phản Hồi

Mọi phản hồi máy chủ bắt đầu bằng một mã ba chữ số. Chữ số đầu tiên cho máy khách biết điều gì đã xảy ra:

2xx — Thành công. Hành động được yêu cầu đã hoàn thành.
3xx — Trung gian. Máy chủ cần thêm dữ liệu đầu vào (được sử dụng sau DATA).
4xx — Lỗi tạm thời. Máy khách nên thử lại sau. Ví dụ: hộp thư đầy (452), máy chủ bận (421).
5xx — Lỗi vĩnh viễn. Không thử lại. Ví dụ: người dùng không rõ (550), lỗi cú pháp (500), từ chối relay (553).

Chữ số thứ hai hạn chế danh mục: x0x = cú pháp, x1x = thông tin, x2x = kết nối, x5x = hệ thống thư. RFC 3463 mở rộng thêm các mã trạng thái được cải thiện như 5.1.1 (hộp thư đích xấu).

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

Envelope Vs. Headers

Một sự phân biệt quan trọng trong SMTP là giữa envelope và message headers. Envelope (MAIL FROM và RCPT TO) kiểm soát định tuyến — nó cho máy chủ biết nơi cần gửi thông báo. Message headers (From:, To:, Subject:) là một phần của thân thông báo được truyền trong DATA và là những gì người nhận thấy. Những cái này có thể khác nhau, và hợp pháp trong các trường hợp như danh sách gửi thư, BCC và chuyển tiếp.

Quá Trình Tra Cứu MX

Khi máy khách cần gửi đến user@example.com, nó truy vấn DNS để tìm MX records cho example.com. Quá trình được định nghĩa bởi RFC 5321:

Tra cứu MX records cho tên miền. Sắp xếp theo ưu tiên (số thấp hơn = ưu tiên cao hơn).
Nếu không có MX records, quay lại A hoặc AAAA record cho chính tên miền.
Nếu MX record chỉ đến . (một "null MX" theo RFC 7505), tên miền không chấp nhận thư.
Thử từng host MX theo thứ tự ưu tiên. Nếu máy chủ trả về lỗi 4xx, thử host tiếp theo.

Độ Dài Dòng và Tính Minh Bạch Dữ Liệu

SMTP yêu cầu các dòng trong thông báo không dài hơn 998 ký tự (không bao gồm CRLF), với giới hạn khuyến nghị là 78 ký tự. Dấu hiệu kết thúc dữ liệu là một dòng chứa chỉ một dấu chấm (.). Nếu một dòng trong thân thông báo bắt đầu bằng một dấu chấm, máy khách phải "dot-stuff" nó bằng cách thêm một dấu chấm bổ sung vào phía trước, và máy chủ phải loại bỏ nó.

Timeout

RFC 5321 chỉ định các timeout tối thiểu mà máy khách PHẢI tuân thủ:

Lời chào ban đầu: 5 phút
Lệnh MAIL: 5 phút
Lệnh RCPT: 5 phút
Bắt đầu DATA: 2 phút
Khối dữ liệu: 3 phút
Kết thúc DATA (dấu chấm cuối cùng): 10 phút

Những timeout rộng rãi này tồn tại vì các máy chủ nhận có thể thực hiện các kiểm tra tốn kém (lọc spam, quét virus) trước khi phản hồi dấu chấm cuối cùng.

Ví Dụ SMTP

Một giao dịch SMTP hoàn chỉnh để gửi một thông báo:

# Máy khách kết nối với cổng 25 của MX server của người nhận S: 220 mx.example.com ESMTP ready C: EHLO sender.example.net S: 250-mx.example.com Hello sender.example.net S: 250-SIZE 52428800 S: 250-8BITMIME S: 250-STARTTLS S: 250-ENHANCEDSTATUSCODES S: 250 PIPELINING # Người gửi envelope (return-path cho các phản hồi) C: MAIL FROM:<alice@sender.example.net> S: 250 2.1.0 OK # Người nhận envelope C: RCPT TO:<bob@example.com> S: 250 2.1.5 OK # Bắt đầu truyền dữ liệu thông báo C: DATA S: 354 Start mail input; end with <CRLF>.<CRLF> C: From: Alice <alice@sender.example.net> C: To: Bob <bob@example.com> C: Subject: Meeting tomorrow C: Date: Wed, 11 Mar 2026 10:00:00 -0500 C: Message-ID: <abc123@sender.example.net> C: C: Hi Bob, are we still on for tomorrow? C: . S: 250 2.0.0 OK, message accepted for delivery C: QUIT S: 221 2.0.0 mx.example.com closing connection

Những Sai Lầm Phổ Biến

Nhầm lẫn địa chỉ envelope và header. Địa chỉ người gửi envelope MAIL FROM không giống với header From:. Kiểm tra SPF kiểm tra người gửi envelope; DKIM ký header. Sai lầm này gây ra lỗi xác thực.
Bỏ qua sự phân biệt 4xx vs. 5xx. Một 450 có nghĩa là "thử lại sau" — bạn nên xếp hàng đợi và thử lại với backoff theo cấp số nhân. Một 550 có nghĩa là "không bao giờ sẽ hoạt động" — tiếp tục thử lại tạo ra lưu lượng không cần thiết và có thể làm hại danh tiếng người gửi của bạn.
Không xử lý các phản hồi nhiều dòng. Một phản hồi như 250- (có dấu gạch ngang) có nghĩa là có thêm dòng theo sau. Chỉ 250 (có dấu cách) báo hiệu dòng cuối cùng.
Gửi mà không có EHLO. Sử dụng lệnh HELO cũ hơn thay vì EHLO có nghĩa là bạn sẽ không khám phá các tiện ích mở rộng máy chủ như STARTTLS, SIZE hoặc PIPELINING. Luôn sử dụng EHLO.
Vượt quá giới hạn độ dài dòng. Các dòng dài hơn 998 ký tự vi phạm thông số kỹ thuật và có thể gây hỏng thông báo. Sử dụng mã hóa MIME cho nội dung dài.
Bỏ qua người gửi null. Các thông báo phản hồi (DSNs) sử dụng một MAIL FROM:<> trống rỗng. Từ chối người gửi null phá vỡ cơ chế ngăn chặn vòng phản hồi.
Không thực hiện dot-stuffing. Nếu thân thông báo của bạn có một dòng bắt đầu bằng ., máy chủ sẽ hiểu nó là kết thúc dữ liệu trừ khi bạn nhân đôi dấu chấm.

Tác Động Khả Năng Giao Hàng

Tuân thủ RFC 5321 trực tiếp ảnh hưởng đến việc email của bạn có đạt đến hộp thư đến hay không:

Tên máy chủ EHLO thích hợp. Tên máy chủ EHLO của bạn sẽ được phân giải trong DNS (chuyển tiếp và ngược lại). Nhiều máy chủ nhận kiểm tra rằng tên EHLO có bản ghi A/AAAA hợp lệ và DNS ngược cho IP của bạn khớp. Không khớp là tín hiệu spam.
Xử lý phản hồi. RFC 5321 yêu cầu người gửi xử lý các phản hồi. Nếu bạn bỏ qua DSNs, bạn sẽ tiếp tục gửi đến các địa chỉ không hợp lệ, điều này phá hủy danh tiếng người gửi của bạn. Các nhà cung cấp hộp thư theo dõi tỷ lệ phản hồi của bạn chặt chẽ.
Hành vi thử lại. Logic thử lại thích hợp với backoff theo cấp số nhân cho các lỗi 4xx cho thấy bạn là một người gửi hoạt động tốt. Hành vi thử lại tích cực có thể kích hoạt giới hạn tốc độ hoặc danh sách chặn.
Hành vi kết nối. Mở quá nhiều kết nối đồng thời với một MX duy nhất hoặc kết nối lại quá nhanh sau khi bị từ chối là các mẫu được liên kết với spam. Tôn trọng giới hạn kết nối và điều tiết thích hợp.
Sự liên kết envelope. SPF và DMARC dựa vào tên miền MAIL FROM. Đảm bảo tên miền người gửi envelope của bạn phù hợp với tên miền header From: của bạn là điều cần thiết để vượt qua các kiểm tra xác thực.