RFC 5598 – Kiến trúc Email Internet

Informational Core SMTP & Message Format Published March 2026

ELI5: Hãy coi email như một hệ thống giao hàng. Có người viết thư (tác giả), bưu điện địa phương chấp nhận nó (gửi), các cơ sở phân loại định tuyến nó khắp đất nước (chuyển tiếp), và bưu điện địa phương tại điểm đến đặt nó vào hộp thư của bạn (giao hàng). RFC 5598 đặt tên cho mọi vai trò và quy trình trong hệ thống này để khi các RFC khác nói về "MTA" hoặc "MSA," mọi người đều hiểu cùng một điều.

RFC Này Tồn Tại Vì Lý Do Gì

Trước RFC 5598, cộng đồng email sử dụng các thuật ngữ như "MTA," "relay," và "gateway" một cách lỏng lẻo và không nhất quán. Các RFC khác nhau sử dụng thuật ngữ khác nhau cho các khái niệm tương tự. Điều này tạo ra sự nhầm lẫn thực sự, đặc biệt khi các cơ chế xác thực như SPF, DKIM, và DMARC cần các định nghĩa chính xác về ai đang làm gì trong đường dẫn tin nhắn.

Được xuất bản vào năm 2009 bởi Dave Crocker, RFC 5598 cung cấp một mô hình kiến trúc toàn diện cho email internet. Đây không phải là đặc tả giao thức — nó không định nghĩa bất kỳ định dạng dây nào mới hoặc lệnh. Thay vào đó, nó là một khung tham chiếu đặt tên và định nghĩa mọi diễn viên, vai trò và chức năng trong hệ sinh thái email. Hầu như mọi RFC email hiện đại đều tham chiếu đến thuật ngữ của 5598.

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

RFC 5598 chia hệ thống email thành các thành phần chức năng riêng biệt được tổ chức xung quanh hành trình của tin nhắn từ tác giả đến người nhận.

Bốn Môi Trường Chính

Kiến trúc xác định bốn môi trường hoạt động mà thông qua đó một tin nhắn đi qua:

Môi trường Mail User Agent (MUA): Nơi người dùng soạn và đọc tin nhắn. Ứng dụng email của bạn — Gmail, Outlook, Thunderbird, hoặc ứng dụng của bạn gọi API.
Môi trường Mail Submission Agent (MSA): Dịch vụ chấp nhận tin nhắn từ MUA để gửi vào hệ thống email. Hoạt động trên cổng 587 theo RFC 6409, yêu cầu xác thực.
Môi trường Mail Transfer Agent (MTA): Cơ sở hạ tầng định tuyến cốt lõi. Các MTA chuyển tiếp tin nhắn qua internet bằng SMTP (RFC 5321) trên cổng 25.
Môi trường Mail Delivery Agent (MDA): Hệ thống cuối cùng đặt tin nhắn vào hộp thư của người nhận, làm cho nó có sẵn thông qua IMAP, POP3, hoặc webmail.

Dòng Tin Nhắn

# Vòng đời của một tin nhắn email Tác giả (MUA) --soạn--> MSA --gửi--> MTA --chuyển tiếp--> MTA --gửi--> MDA --lưu trữ--> Người nhận (MUA) # | | | | | # Soạn tin nhắn Xác thực, Định tuyến qua Định tuyến qua Lưu trữ # với tiêu đề xác nhận, tra cứu DNS MX tra cứu DNS MX trong # áp dụng chính sách hộp thư

Các Diễn Viên Chính và Vai Trò

Diễn Viên	Viết Tắt	Vai Trò
Mail User Agent	MUA	Soạn và hiển thị tin nhắn cho người dùng. Ứng dụng email.
Mail Submission Agent	MSA	Chấp nhận tin nhắn từ MUA được xác thực, thực thi chính sách và đưa chúng vào cơ sở hạ tầng MTA.
Mail Transfer Agent	MTA	Định tuyến và chuyển tiếp tin nhắn giữa các miền bằng SMTP. "Xương sống" của email.
Mail Delivery Agent	MDA	Gửi cuối cùng vào hộp thư của người nhận. Có thể áp dụng quy tắc lọc.
Mail Store	MS	Lưu trữ tin nhắn và cung cấp quyền truy cập qua IMAP/POP3/JMAP.

Các Loại Danh Tính

RFC 5598 cẩn thận phân biệt các danh tính khác nhau được liên kết với một tin nhắn:

Danh Tính	Nơi Nó Xuất Hiện	Ý Nghĩa Của Nó
Tác Giả	`From:` tiêu đề	Người hoặc thực thể đã viết tin nhắn
Người Gửi	`Sender:` tiêu đề	Đại lý thực sự truyền tin nhắn (khi khác với tác giả)
Return-Path	`MAIL FROM` phong bì / `Return-Path:` tiêu đề	Nơi các thư bị trả lại nên được gửi; bên chịu trách nhiệm về vận chuyển
Người Nhận	`RCPT TO` phong bì / `To:`/`Cc:` tiêu đề	Những người nhận dự định

Sự phân biệt này rất quan trọng đối với xác thực. SPF xác nhận danh tính Return-Path. DKIM có thể ký thay mặt cho Tác Giả hoặc một bên trung gian. DMARC căn chỉnh danh tính Tác Giả với kết quả SPF và DKIM.

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

Các Trung Gian

RFC 5598 xác định một danh mục quan trọng của các diễn viên được gọi là trung gian — các thực thể nhận một tin nhắn và sau đó đăng lại nó, có khả năng sửa đổi nó theo cách nào đó:

Danh Sách Gửi Thư: Nhận tin nhắn, thêm tiêu đề danh sách, có thể sửa đổi chủ đề hoặc nội dung, và phân phối lại cho những người đăng ký. Danh sách trở thành người gửi MAIL FROM mới.
Cổng: Chuyển đổi giữa email và một hệ thống nhắn tin khác (ví dụ: email-to-SMS, email-to-fax).
Người Chuyển Tiếp/Bên Phân Phối Lại: Chuyển tiếp hoặc phân phối lại email, chẳng hạn như địa chỉ chuyển tiếp cựu sinh viên.

Trung gian là lý do chính khiến xác thực email trở nên phức tạp. Khi danh sách gửi thư thay đổi người gửi phong bì và sửa đổi tin nhắn, SPF bị phá vỡ (IP người gửi mới không được phép cho miền gốc) và DKIM có thể bị phá vỡ (nội dung bị sửa đổi). Đây chính xác là vấn đề mà ARC (RFC 8617) được thiết kế để giải quyết.

ADMD: Miền Quản Lý Hành Chính

RFC 5598 giới thiệu khái niệm của một ADMD — ranh giới hành chính của một hoạt động email. Một ADMD là một tổ chức vận hành một hoặc nhiều dịch vụ email dưới một thẩm quyền hành chính duy nhất. Ví dụ:

Một công ty vận hành máy chủ Exchange của riêng nó là một ADMD.
Gmail/Google Workspace là một ADMD.
Một dịch vụ email giao dịch như MailerToGo là một ADMD.

Tin nhắn vượt qua ranh giới ADMD khi chúng rời khỏi cơ sở hạ tầng email của một tổ chức và vào cơ sở của tổ chức khác. Xác thực và quyết định tin tưởng xảy ra tại các ranh giới này.

Phong Bì so với Nội Dung

Kiến trúc chính thức hóa hai lớp của mọi tin nhắn email:

Phong Bì: Thông tin cấp SMTP (MAIL FROM, RCPT TO) được sử dụng để định tuyến. Được tạo trong khi gửi và sửa đổi ở mỗi bước.
Nội Dung: Tiêu đề tin nhắn và nội dung theo định nghĩa của RFC 5322. Dự định không thay đổi sau khi soạn thảo, mặc dù trung gian có thể sửa đổi nó.

Lỗi Phổ Biến

Nhầm lẫn MTA và MSA. MSA (cổng 587, được xác thực) và MTA (cổng 25, server-to-server) phục vụ các mục đích khác nhau. Gửi email ứng dụng trực tiếp đến MTA từ xa trên cổng 25 — bỏ qua MSA — bỏ qua xác thực và thực thi chính sách. Hầu hết các nhà cung cấp đám mây chặn cổng 25 dành cho lưu lượng đi vì lý do này.
Bỏ qua vấn đề trung gian. Nếu bạn thực thi DMARC nghiêm ngặt (p=reject) mà không xem xét rằng tin nhắn của bạn có thể đi qua danh sách gửi thư, những tin nhắn được chuyển tiếp đó sẽ bị từ chối tại đích. Hiểu khái niệm trung gian giúp bạn lập kế hoạch cho điều này.
Coi From: là người gửi. Tiêu đề From: xác định tác giả, không phải người gửi vận chuyển. SPF kiểm tra người gửi phong bì, không phải tiêu đề From. Sự phân biệt này là toàn bộ cơ sở cho căn chỉnh DMARC.
Giả định một cấu trúc phẳng. Tin nhắn không phải lúc nào cũng đi trực tiếp từ người gửi đến người nhận. Chúng có thể đi qua nhiều MTA, danh sách gửi thư, dịch vụ chuyển tiếp và cổng. Mỗi bước có thể sửa đổi phong bì và có khả năng là nội dung.
Không hiểu ranh giới ADMD. Khi bạn ủy thác gửi cho một dịch vụ email, tin nhắn vượt qua ranh giới ADMD. SPF, DKIM, và DMARC phải được cấu hình để tính đến sự ủy thác này.

Tác Động Đến Khả Năng Gửi

Kiến trúc gửi thích hợp. Sử dụng MSA (cổng 587 với xác thực) thay vì tiêm trực tiếp vào MTA đảm bảo tin nhắn của bạn được xác thực đúng cách và tuân thủ chính sách ngay từ đầu. Các dịch vụ như MailerToGo hoạt động như MSA của bạn.
Căn chỉnh xác thực. Hiểu được danh tính nào mà mỗi cơ chế xác thực kiểm tra — SPF kiểm tra Return-Path, DKIM ký thay mặt cho một miền, DMARC căn chỉnh những điều này với tiêu đề From — yêu cầu hiểu mô hình danh tính của RFC 5598.
Xử lý chuyển tiếp và danh sách. Nếu những người nhận của bạn sử dụng dịch vụ chuyển tiếp hoặc danh sách gửi thư (trung gian), tin nhắn của bạn có thể không vượt qua xác thực tại đích cuối cùng. Hiểu vai trò trung gian giúp bạn chẩn đoán "tại sao tin nhắn DMARC-passing của tôi bị từ chối?"
Xử lý thư bị trả lại. Kiến trúc phân biệt giữa tác giả (tiêu đề From) và return-path (MAIL FROM). Thư bị trả lại đi đến return-path. Nếu bạn thiết lập return-path của mình một cách chính xác, bạn có thể xử lý thư bị trả lại tự động mà không nhầm lẫn chúng với các trả lời cho tác giả.