← RFC Reference

Giải phẫu Email Headers

Mọi trường tiêu đề quan trọng trong thư điện tử được giải thích — ý nghĩa, ai đặt nó và lý do nó quan trọng. Bao gồm một ví dụ thực tế được chú thích đầy đủ.

Một Ví Dụ Hoàn Chỉnh

Dưới đây là các tiêu đề của một thư thực tế, từ trên xuống dưới, như chúng xuất hiện trong hộp thư của người nhận. Chúng ta sẽ phân tích từng cái một.

Bây giờ chúng ta hãy xem xét từng tiêu đề.

Tiêu Đề Nhận Dạng

From

Tác giả của thư, được xác định bởi RFC 5322. Đây là những gì người nhận thấy trong ứng dụng mail của họ. Nó bao gồm tên hiển thị tùy chọn (Alice) và địa chỉ hộp thư (alice@example.com). Các kiểm tra căn chỉnh DMARC được thực hiện dựa trên miền trong tiêu đề này.

From không giống với envelope sender. Envelope sender (MAIL FROM trong SMTP) có thể hoàn toàn khác. Tiêu đề From: được đặt bởi tác giả thư; envelope sender được đặt bởi hệ thống gửi.

To, Cc, Bcc

To: và Cc: là tiêu đề hiển thị — chúng chỉ ra đối tượng dự định nhưng không kiểm soát giao hàng. Các người nhận thực tế được xác định bởi các lệnh SMTP RCPT TO, có thể bao gồm người nhận Bcc không được liệt kê trong bất kỳ tiêu đề nào. Một thư có thể có tiêu đề To: liệt kê các địa chỉ không trong RCPT TO, và ngược lại (đây là cách Bcc hoạt động).

Reply-To

Không hiển thị trong ví dụ của chúng tôi, nhưng phổ biến. Chỉ định nơi các trả lời nên được hướng tới nếu khác với From:. Thường được sử dụng khi thư được gửi từ địa chỉ không trả lời nhưng trả lời nên tới hỗ trợ:

Sender

Được sử dụng khi thực thể chịu trách nhiệm gửi khác với tác giả. Nếu trợ lý của Alice gửi thư thay mặt cho cô ấy, các tiêu đề có thể đọc From: Alice và Sender: Assistant. Hầu hết các thư bỏ qua tiêu đề này.

Xác Định Thư

Message-ID

Một định danh duy nhất toàn cầu cho thư này, được tạo bởi người gửi. Định dạng là <unique-part@domain>. Điều này rất quan trọng để phân luồng, khử trùng lặp và tương quan bounce. Mọi thư đều nên có một. Nếu hệ thống gửi của bạn không đặt nó, MTA đầu tiên sẽ tạo một — nhưng sau đó bạn mất khả năng tương quan các bounce với các thư được gửi cụ thể.

In-Reply-To và References

Được sử dụng để phân luồng. In-Reply-To chứa Message-ID của thư đang được trả lời. References chứa toàn bộ chuỗi giá trị Message-ID trong chủ đề. Các ứng dụng mail sử dụng những cái này để nhóm các cuộc trò chuyện:

Ngày và Chủ Đề

Date

Ngày và giờ thư được soạn, được đặt bởi người gửi. Định dạng được chỉ định trong RFC 5322. Nó không phải là thời gian giao hàng. Một thư có thể nằm trong hàng đợi trong nhiều giờ hoặc nhiều ngày trước khi giao hàng. Luôn bao gồm độ lệch múi giờ.

Subject

Văn bản dạng tự do tóm tắt thư. Không giới hạn độ dài trong spec, nhưng các ứng dụng mail cắt ngắn ở các độ dài khác nhau. Giữ nó dưới 60 ký tự để hiển thị nhất quán. Các ký tự không phải ASCII phải được mã hóa bằng mã hóa RFC 2047 (ví dụ: =?UTF-8?Q?...?=), mặc dù hầu hết các hệ thống mail hiện đại xử lý điều này một cách trong suốt.

Chuỗi Received

Mỗi máy chủ xử lý thư thêm một tiêu đề Received: ở phía trước. Chúng được đọc từ dưới lên trên — hop cũ nhất ở dưới cùng, hop gần đây nhất ở trên cùng. Mỗi tiêu đề ghi lại:

• from — Máy chủ đã gửi thư (tên máy chủ và IP)
• by — Máy chủ nhận nó
• with — Giao thức được sử dụng (ESMTP, ESMTPS cho TLS, LMTP cho giao hàng cục bộ)
• id — ID hàng đợi của máy chủ nhận
• for — Người nhận (có thể bị bỏ qua vì quyền riêng tư với nhiều người nhận)
• timestamp — Khi hop này nhận thư

Chuỗi Received không có giá trị để gỡ lỗi độ trễ giao hàng. So sánh dấu thời gian giữa các hop để tìm nơi mất thời gian. Lưu ý: các tiêu đề Received: từ phía người gửi có thể được giả mạo. Chỉ tin tưởng các tiêu đề được thêm bởi cơ sở hạ tầng của riêng bạn.

Return-Path

Được đặt bởi MTA giao hàng cuối cùng, điều này ghi lại envelope sender SMTP (MAIL FROM). Đây là nơi các bounce được gửi. Trong ví dụ này, mã hóa VERP được sử dụng — người nhận ban đầu (alice@example.com) được mã hóa vào phần cục bộ của địa chỉ bounce.

Return-Path không được đặt bởi tác giả thư; nó được trích xuất từ phiên SMTP và được thêm bởi máy chủ giao hàng. Nên có chính xác một tiêu đề Return-Path trong một thư được giao hàng.

Tiêu Đề Xác Thực

DKIM-Signature

Được thêm bởi máy chủ gửi. Trường d= xác định miền ký (được sử dụng để căn chỉnh DMARC). Trường s= là bộ chọn được sử dụng để tra cứu khóa công khai trong DNS. Trường h= liệt kê những tiêu đề được ký. Xem Email Authentication Explained để biết quá trình xác minh đầy đủ.

Authentication-Results

Được thêm bởi máy chủ nhận (RFC 8601). Đây là bản ghi có thẩm quyền về các kiểm tra xác thực cho thư này tại hop này. Authserv-id (mx1.example.net) xác định máy chủ nào thực hiện kiểm tra. Nó ghi lại các kết quả SPF, DKIM và DMARC, bao gồm các định danh được kiểm tra.

Lưu ý bảo mật: Các tiêu đề Authentication-Results giả mạo từ các nguồn bên ngoài nên được xóa bởi border MTA. Chỉ tin tưởng tiêu đề này khi nó được thêm bởi cơ sở hạ tầng của riêng bạn.

Tiêu Đề MIME

MIME-Version

Chỉ ra thư sử dụng MIME (RFC 2045). Điều này luôn là 1.0 và nên có trong mọi thư. Nếu không có nó, thư được hiểu là văn bản US-ASCII thuần túy.

Content-Type

Mô tả loại phương tiện của phần thân thư. Các giá trị phổ biến:

• text/plain — Văn bản thuần túy
• text/html — Nội dung HTML
• multipart/alternative — Nhiều phiên bản cùng nội dung (thường là văn bản và HTML). Ứng dụng mail chọn cái tốt nhất.
• multipart/mixed — Thư có đính kèm
• multipart/related — HTML với hình ảnh nội tuyến

Tham số boundary xác định dấu phân cách giữa các phần MIME. Xem RFC 2046 để biết chi tiết.

Content-Transfer-Encoding

Cách mã hóa phần thân để vận chuyển an toàn. Các giá trị phổ biến: 7bit, quoted-printable, base64. Đính kèm sử dụng base64. Phần thân thư HTML thường sử dụng quoted-printable để xử lý các ký tự không phải ASCII trong khi vẫn có thể đọc được phần lớn.

Tiêu Đề Quản Lý Danh Sách

RFC 2369 xác định List-Unsubscribe, cung cấp URL và/hoặc địa chỉ mailto để hủy đăng ký. RFC 8058 thêm List-Unsubscribe-Post, cho phép hủy đăng ký một cú nhấp chuột trực tiếp từ UI của ứng dụng mail mà không cần mở trình duyệt. Gmail và các nhà cung cấp lớn khác yêu cầu cả hai tiêu đề cho thư số lượng lớn và tiếp thị.

Tiêu Đề Bạn Không Nên Nhìn Thấy (Nhưng Đôi Khi Có)

X-Mailer / User-Agent

Xác định ứng dụng mail hoặc phần mềm gửi. Đôi khi được sử dụng bởi các bộ lọc thư rác như một tín hiệu. Các hệ thống gửi hiện đại thường bỏ qua cái này để giảm bề mặt dấu vân tay.

X-Priority / Importance

Các tiêu đề không chuẩn cố gắng đặt ưu tiên thư. Hầu hết các ứng dụng mail bỏ qua chúng. Một số bộ lọc thư rác coi các dấu ưu tiên cao là tín hiệu tiêu cực.

X-Spam-Status / X-Spam-Score

Được thêm bởi các hệ thống lọc thư rác (như SpamAssassin). Không chuẩn hóa, nhưng được sử dụng rộng rãi trong nội bộ. Những cái này không nên có trong thư gửi đi — chúng được thêm bởi cơ sở hạ tầng nhận.

Những Gì Có Thể Sai

Missing Message-ID

Nếu bạn không đặt Message-ID, MTA đầu tiên sẽ thêm một. Nhưng bạn mất khả năng tương quan các thư được gửi với các bounce và thông báo giao hàng. Luôn tạo Message-ID của riêng bạn trước khi gửi.

From and envelope sender confusion

Một nguồn vấn đề giao hàng phổ biến. Tiêu đề From: hiển thị alice@example.com, nhưng envelope sender là bounce@esp.com. SPF xác thực miền ESP, không phải miền của bạn. Nếu chữ ký DKIM của bạn cũng sử dụng d=esp.com, việc căn chỉnh DMARC sẽ thất bại cho cả hai cơ chế. Cách khắc phục: ký bằng d=example.com để DKIM căn chỉnh.

Duplicate or conflicting headers

RFC 5322 chỉ định rằng một số tiêu đề (như From:, Date:, Message-ID:) phải xuất hiện chính xác một lần. Các bản sao có thể gây ra hành vi không thể dự đoán — các ứng dụng mail khác nhau có thể chọn các giá trị khác nhau. Một số bộ lọc thư rác coi các tiêu đề From: trùng lặp là đáng ngờ.

Missing Date header

Nếu không có tiêu đề Date:, MTA nhận hoặc ứng dụng mail sẽ thay thế dấu thời gian của chính nó, có thể khác đáng kể. Một số bộ lọc thư rác phạt các thư không có tiêu đề Date.

Received chain forgery

Bất kỳ ai cũng có thể thêm các tiêu đề Received: giả vào phía trước thư trước khi gửi. MTA nhận chỉ có thể tin tưởng các tiêu đề nó đã thêm. Khi gỡ lỗi, hãy bắt đầu từ trên cùng (gần đây nhất) và làm việc xuống dưới, và dừng tin tưởng một khi bạn chạm vào ranh giới giữa cơ sở hạ tầng của bạn và thế giới bên ngoài.

Những Điều Cần Ghi Nhớ

• Tiêu đề là siêu dữ liệu về thư. Envelope (MAIL FROM / RCPT TO) kiểm soát giao hàng; tiêu đề dùng để hiển thị và xử lý.
• From: là những gì người nhận thấy. Return-Path: là nơi các bounce đi. Chúng thường khác nhau.
• Received: tiêu đề tạo thành chuỗi từ dưới lên trên hiển thị đường dẫn của thư. Chỉ tin tưởng các tiêu đề từ cơ sở hạ tầng của riêng bạn.
• Authentication-Results: là phán xét của máy chủ nhận về SPF, DKIM và DMARC.
• Luôn đặt Message-ID, Date, From, MIME-Version và Content-Type.
• Đối với thư số lượng lớn/tiếp thị, bao gồm List-Unsubscribe và List-Unsubscribe-Post.

Đọc Thêm

Related RFCs