← RFC Reference

Vòng Đời của Email

Từ lúc bạn nhấp "Gửi" đến lúc một tin nhắn xuất hiện trong hộp thư của ai đó — mỗi bước, mỗi giao thức, mỗi quyết định trên đường đi.

Những Người Tham Gia

Kiến trúc thư Internet (RFC 5598) xác định các vai trò tham gia vào việc gửi email. Hiểu những vai trò này là điều cần thiết vì cùng một phần mềm thường đảm nhận nhiều vai trò, và ranh giới giữa chúng rất quan trọng để hiểu cách thức email được truyền tải.

Trong thực tế, những vai trò này thường được gộp lại. Cơ sở hạ tầng của Gmail đồng thời là MSA, MTA, MX, MDA và MRA. Postfix có thể hoạt động như cả MSA và MTA. Nhưng những vai trò logic vẫn khác biệt, và hiểu chúng giúp bạn gỡ rối các vấn đề về gửi email.

Giai đoạn 1: Soạn thảo (MUA)

Vòng đời bắt đầu khi người dùng soạn một tin nhắn trong ứng dụng email của họ, hoặc khi một ứng dụng tạo một tin nhắn theo cách lập trình (thông qua API hoặc thư viện SMTP).

MUA xây dựng tin nhắn theo RFC 5322 (Định dạng tin nhắn Internet):

Những quyết định chính ở giai đoạn này:

• Tiêu đề From: xác định tác giả cho người nhận (và là những gì DMARC kiểm tra sự liên kết).
• Message-ID: được tạo — một mã định danh duy nhất trên toàn cầu cho tin nhắn cụ thể này.
• Mã hóa MIME được áp dụng: các tệp đính kèm được mã hóa Base64, phần thân được cấu trúc dưới dạng nhiều phần nếu cần.
• MUA không thêm các tiêu đề Received:. Những tiêu đề này được thêm bởi mỗi máy chủ xử lý tin nhắn.

Giai đoạn 2: Gửi (MUA → MSA)

MUA kết nối với MSA (RFC 6409) để gửi tin nhắn. Đây là bước gửi.

Những gì MSA thực hiện khi nhận tin nhắn:

• Xác thực người gửi. MUA phải cung cấp thông tin xác thực hợp lệ (tên người dùng/mật khẩu qua AUTH). Đây là cách ngăn chặn những người lạ sử dụng máy chủ email của bạn như một relay mở.
• Xác thực phong bì. MSA có thể kiểm tra xem miền MAIL FROM có khớp với miền của người dùng đã xác thực hay không.
• Thêm tiêu đề Received:. Điều này ghi lại bước đầu tiên: ai đã gửi tin nhắn, khi nào và từ IP nào.
• Có thể thêm hoặc sửa các tiêu đề. MSA có thể thêm tiêu đề Date: nếu thiếu, tạo Message-ID: nếu MUA không tạo, và thêm các tiêu đề DKIM-Signature.
• Xếp hàng tin nhắn để gửi. Tin nhắn đi vào hàng đợi gửi đi của MTA.

Đường dẫn gửi API

Khi sử dụng dịch vụ email giao dịch như Mailer To Go, ứng dụng của bạn thường gửi qua API HTTP thay vì SMTP. Máy chủ API chấp nhận tin nhắn, xây dựng phong bì SMTP và tiêu đề, áp dụng ký DKIM và đưa tin nhắn vào hàng đợi MTA. Lệnh gọi API thay thế cả MUA và giao dịch SMTP từ MUA đến MSA, nhưng mọi thứ phía sau vẫn giống nhau.

Giai đoạn 3: Định tuyến và Truyền (MTA → MTA)

MTA gửi bây giờ phải gửi tin nhắn đến miền của người nhận. Đây là giai đoạn relay, được điều chỉnh bởi RFC 5321 (SMTP).

Phân giải DNS

MTA tra cứu các bản ghi MX cho miền của người nhận:

Nó cố gắng MX có ưu tiên thấp nhất trước tiên. Nếu máy chủ đó không thể tiếp cận, nó sẽ quay lại máy chủ tiếp theo. Xem DNS và định tuyến email để biết thuật toán đầy đủ, bao gồm quay lại các bản ghi A/AAAA và xử lý Null MX.

Việc truyền

Ở giai đoạn này:

• STARTTLS mã hóa kết nối. Không có MTA-STS hoặc DANE, MTA gửi sẽ quay lại văn bản thuần túy nếu thương lượng TLS thất bại. Đây là một rủi ro bảo mật — một kẻ tấn công tích cực có thể loại bỏ TLS khỏi kết nối.
• Không sử dụng xác thực (AUTH). SMTP từ máy chủ này sang máy chủ khác trên cổng 25 không yêu cầu thông tin xác thực. Máy chủ nhận phụ thuộc vào địa chỉ IP, SPF, DKIM và DMARC để xác minh người gửi.
• Một tiêu đề Received: khác được thêm vào. Mỗi MTA thêm trước một tiêu đề Received:, xây dựng một chuỗi ghi lại đường dẫn của tin nhắn.
• Tin nhắn có thể đi qua nhiều MTA. Định tuyến nội bộ trong các tổ chức lớn, quy tắc chuyển tiếp và danh sách gửi thư có thể thêm các bước bổ sung.

Xếp hàng và thử lại

Nếu MX nhận trả về lỗi tạm thời 4xx (máy chủ bận, greylisting, giới hạn tốc độ), MTA gửi xếp hàng tin nhắn và thử lại sau. Lịch trình thử lại thường sử dụng backoff theo cấp số nhân: 15 phút, 30 phút, 1 giờ, 2 giờ, v.v. Nếu tin nhắn không thể được gửi sau khoảng thời gian thử lại (thường là 4–5 ngày), MTA tạo ra một thông báo phản hồi (DSN) và gửi lại cho người gửi phong bì.

Giai đoạn 4: Tiếp nhận (MX)

MX nhận (MTA chấp nhận thư đến cho miền của người nhận) là nơi xảy ra hầu hết các bộ lọc. Đây là người canh cổng.

Tại thời điểm kết nối, trước khi bất kỳ nội dung tin nhắn nào đến:

• Kiểm tra danh tiếng IP. MX nhận kiểm tra IP kết nối này với cơ sở dữ liệu danh tiếng nội bộ của nó và các danh sách chặn bên ngoài.
• Kiểm tra DNS ngược. IP nên có bản ghi PTR hợp lệ phân giải lại thành cùng một IP.
• Giới hạn tốc độ. Các kết nối quá mức từ cùng một IP có thể bị điều tiết.

Trong giai đoạn phong bì:

• Xác thực người nhận. Hộp thư có tồn tại không? Nếu không: 550 5.1.1 User unknown.
• Kiểm tra SPF. Miền MAIL FROM được kiểm tra so với bản ghi SPF của nó để xác minh IP gửi được ủy quyền.

Sau DATA (tin nhắn đầy đủ được nhận):

• Xác minh DKIM. Chữ ký DKIM được xác thực so với khóa công khai trong DNS.
• Đánh giá DMARC. Các kết quả SPF và DKIM được kiểm tra để căn chỉnh DMARC với tiêu đề From:.
• Lọc nội dung. Tin nhắn đi qua các bộ lọc spam: phân tích nội dung, kiểm tra URL, phân loại Bayes, mô hình học máy.
• Thêm tiêu đề Authentication-Results. MX ghi lại kết quả của tất cả các kiểm tra xác thực trong tiêu đề Authentication-Results.

Giai đoạn 5: Gửi (MDA)

Mail Delivery Agent lấy tin nhắn đã vượt qua bộ lọc và gửi nó vào hộp thư của người nhận. Trong nhiều hệ thống, MDA được tích hợp vào máy chủ MX thay vì là một quy trình riêng biệt.

Những trách nhiệm của MDA:

• Lựa chọn hộp thư. Xác định hộp thư (tài khoản người dùng) nào sẽ nhận tin nhắn dựa trên địa chỉ RCPT TO, bí danh và quy tắc định tuyến.
• Đặt thư mục. Dựa trên quyết định của bộ lọc spam và quy tắc do người dùng định nghĩa, tin nhắn sẽ đi đến Inbox, thư mục Spam/Junk, nhãn cụ thể (Gmail) hoặc thư mục tùy chỉnh (quy tắc Sieve).
• Lọc Sieve. Nhiều hệ thống thư hỗ trợ Sieve (RFC 5228), một ngôn ngữ để lọc thư được xác định bởi người dùng. Quy tắc có thể lưu trữ tin nhắn vào thư mục, chuyển tiếp chúng, từ chối chúng hoặc kích hoạt trả lời tự động kỳ nghỉ.
• Thực thi hạn ngạch. Nếu hộp thư vượt quá hạn ngạch, MDA có thể từ chối tin nhắn bằng 452 4.2.2 Mailbox full hoặc 552 5.2.2 Mailbox full.
• Thông báo. MDA có thể kích hoạt thông báo đẩy đến các thiết bị của người dùng (cảnh báo thư mới).

Tại điểm này, tin nhắn ở trạng thái yên tĩnh trong kho thư của người nhận. Giao dịch SMTP đã hoàn tất. Trách nhiệm của MTA gửi kết thúc khi nó nhận được 250 OK từ MX nhận.

Giai đoạn 6: Lấy (MRA → MUA)

Ứng dụng email của người nhận lấy tin nhắn từ kho thư bằng một trong ba giao thức:

IMAP (RFC 9051)

Giao thức truy cập thư chiếm ưu thế. IMAP giữ các tin nhắn trên máy chủ và đồng bộ hóa trạng thái (đã đọc/chưa đọc, cờ, thư mục) trên nhiều ứng dụng khách. Ứng dụng khách tải xuống tiêu đề tin nhắn trước tiên và tìm nạp toàn bộ nội dung khi cần. Những thay đổi được thực hiện trên một ứng dụng khách (đánh dấu là đã đọc, di chuyển đến thư mục) sẽ được phản ánh trên tất cả các ứng dụng khách.

POP3 (RFC 1939)

Giao thức cũ hơn, đơn giản hơn. POP3 tải xuống các tin nhắn đến ứng dụng khách và (theo mặc định) xóa chúng khỏi máy chủ. Nó không đồng bộ hóa trạng thái giữa các ứng dụng khách. Phần lớn đã được IMAP thay thế, nhưng vẫn được sử dụng trong một số tình huống.

Truy cập web và API

Giao diện webmail (Gmail, Outlook.com) và ứng dụng di động truy cập kho thư thông qua API độc quyền hoặc JMAP (RFC 8620), bỏ qua IMAP/POP3 hoàn toàn. Tin nhắn không bao giờ rời khỏi máy chủ của nhà cung cấp — ứng dụng khách hiển thị nó thông qua yêu cầu web.

Nơi Xảy Ra Sự Cố: Các Chế Độ Lỗi Ở Mỗi Giai Đoạn

Lỗi gửi

Xác thực thất bại (mật khẩu sai, token hết hạn), MSA từ chối tin nhắn (vượt quá giới hạn kích thước, vi phạm chính sách) hoặc kết nối hết thời gian chờ. Người dùng sẽ thấy một lỗi ngay lập tức.

Lỗi định tuyến

Phân giải DNS thất bại (không có bản ghi MX, timeout DNS), tất cả các máy chủ MX không thể tiếp cận hoặc mỗi MX trả về lỗi vĩnh viễn. Sau khi thử lại hết hạn, người gửi nhận được một phản hồi (DSN).

Từ chối tại thời điểm tiếp nhận

MX nhận từ chối tin nhắn tại thời điểm SMTP: IP bị chặn (550), xác thực thất bại (550 5.7.1), người nhận không xác định (550 5.1.1), hoặc từ chối nội dung (554). MTA gửi tạo thông báo phản hồi cho người gửi phong bì.

Lọc sau khi chấp nhận

MX chấp nhận tin nhắn (250 OK) nhưng MDA định tuyến nó đến thư mục spam dựa trên phân tích nội dung và điểm danh tiếng. Người gửi không nhận được phản hồi — tin nhắn về mặt kỹ thuật đã "được gửi" — nhưng người nhận không bao giờ nhìn thấy nó. Đây là vấn đề về khả năng gửi phổ biến nhất và khó chẩn đoán nhất.

Hộp thư đầy

Hộp thư của người nhận vượt quá hạn ngạch. Tùy thuộc vào việc thực hiện, đây là một từ chối tại thời điểm RCPT TO hoặc một phản hồi được tạo sau khi chấp nhận DATA.

Tiêu Đề Kể Câu Chuyện

Mỗi giai đoạn của vòng đời thêm tiêu đề vào tin nhắn. Đọc tiêu đề từ dưới lên trên để tái cấu trúc hành trình:

Các tiêu đề Received: là những mẫu vết. Mỗi tiêu đề ghi lại máy chủ gửi, máy chủ nhận, giao thức được sử dụng (ESMTP, ESMTPS cho TLS, ESMTPSA cho xác thực+TLS), ID hàng đợi và dấu thời gian. Xem Anatomy of Email Headers để biết hướng dẫn đầy đủ.

Đường Dẫn Email Giao Dịch

Khi một ứng dụng gửi email thông qua dịch vụ như Mailer To Go, vòng đời sẽ hơi khác:

1. Ứng dụng gọi API. Ứng dụng của bạn gửi yêu cầu POST với nội dung tin nhắn, người nhận và siêu dữ liệu.
2. Dịch vụ xây dựng tin nhắn. Nó xây dựng cấu trúc MIME, thêm các tiêu đề bắt buộc (Ngày, Message-ID, List-Unsubscribe nếu áp dụng) và áp dụng ký DKIM bằng khóa của miền của bạn.
3. MTA của dịch vụ gửi tin nhắn. Tin nhắn được gửi từ IP của dịch vụ đến MX của người nhận thông qua SMTP trên cổng 25, với STARTTLS.
4. Phần còn lại giống hệt nhau. Tiếp nhận MX, kiểm tra xác thực, lọc nội dung, gửi MDA và lấy ứng dụng khách đều diễn ra như được mô tả ở trên.

Sự khác biệt chính: ứng dụng của bạn không bao giờ nói chuyện SMTP trực tiếp. API loại bỏ toàn bộ lớp gửi. Nhưng tin nhắn vẫn đi qua cùng một cơ sở hạ tầng, trải qua các kiểm tra xác thực tương tự và được đánh giá bởi các bộ lọc spam tương tự.

Những Điểm Chính

• Email có sáu giai đoạn riên biệt: soạn thảo, gửi, truyền, tiếp nhận, gửi và lấy. Mỗi giai đoạn liên quan đến các giao thức khác nhau và những người tham gia khác nhau.
• Phong bì và tin nhắn là riêng biệt. MAIL FROM / RCPT TO (phong bì) có thể khác với tiêu đề From: / To: (tin nhắn). Sự phân biệt này quan trọng đối với xác thực, phản hồi và Bcc.
• Hầu hết bộ lọc xảy ra tại thời điểm tiếp nhận. MX nhận là nơi xác thực, danh tiếng và nội dung được đánh giá. Đây là giai đoạn xác định inbox so với spam.
• 250 OK có nghĩa là được chấp nhận, không phải được gửi đến hộp thư đến. MX nhận vẫn có thể định tuyến tin nhắn đến spam, hoặc MDA có thể từ chối nó sau (hộp thư đầy, quy tắc Sieve).
• Tiêu đề Received: ghi lại hành trình. Đọc chúng từ dưới lên trên để theo dõi đường đi của tin nhắn. Chúng là công cụ gỡ rối duy nhất hữu ích nhất cho các vấn đề về gửi.
• Mỗi bước thêm độ trễ và rủi ro. Nhiều bước hơn có nghĩa là nhiều cơ hội hơn để xảy ra lỗi, trì hoãn hoặc sửa đổi nội dung (có thể phá vỡ chữ ký DKIM).

Tìm Hiểu Thêm

Related RFCs