RFC 2049: MIME Phần 5 — Tiêu chí Tuân thủ và Ví dụ

Standards Track MIME — Multipurpose Internet Mail Extensions Published March 2026

ELI5: RFC 2045–2047 định nghĩa các quy tắc của MIME. RFC 2049 là bài kiểm tra: nó quy định chính xác những gì phần mềm của bạn phải làm để vượt qua kiểm tra "tuân thủ MIME" và cung cấp các ví dụ cụ thể để kiểm tra cách triển khai của bạn. Nếu MIME là một quy tắc xây dựng, đây là danh sách kiểm tra thanh tra.

Tại Sao Điều Này Tồn Tại

Thông số MIME trải dài bốn RFC kỹ thuật (2045, 2046, 2047, và 2048). Những người triển khai cần một câu trả lời rõ ràng: "phần tối thiểu phần mềm của tôi phải xử lý để tuân thủ MIME là gì?" RFC 2049 cung cấp câu trả lời đó, cùng với các thông điệp kiểm tra chuẩn mà những người triển khai có thể sử dụng để xác minh bộ phân tích cú pháp của họ.

Không có tài liệu tuân thủ, các triển khai khác nhau sẽ hỗ trợ các tập hợp con khác nhau của MIME, dẫn đến lỗi khả năng tương tác. RFC 2049 đặt ra ngưỡng tối thiểu: mọi hệ thống nhận biết MIME phải ít nhất xử lý các loại nội dung, mã hóa và cấu trúc này.

Cách Nó Hoạt Động

RFC 2049 xác định hai mức độ tuân thủ, mỗi mức có yêu cầu cụ thể.

Yêu Cầu Đối Với Tác Nhân Gửi

Một tác nhân gửi tuân thủ MIME (MUA hoặc thư viện email) phải:

Luôn bao gồm MIME-Version: 1.0 trong mọi thông điệp sử dụng các tính năng MIME.
Bao gồm tiêu đề Content-Type khi nội dung là bất cứ thứ gì khác ngoài văn bản US-ASCII thuần túy.
Sử dụng Content-Transfer-Encoding hợp lệ để đảm bảo nội dung thông điệp có thể vượt qua các cổng SMTP 7-bit (base64 hoặc quoted-printable cho nội dung không phải ASCII).
Mã hóa các trường tiêu đề đúng cách sử dụng các từ được mã hóa RFC 2047 khi các ký tự không phải ASCII xuất hiện trong các tiêu đề như tên hiển thị Subject hoặc From.
Tạo ranh giới multipart hợp lệ không xuất hiện trong bất kỳ phần nội dung đóng nào.

Yêu Cầu Đối Với Tác Nhân Nhận

Một tác nhân nhận tuân thủ MIME phải:

Nhận dạng MIME-Version: 1.0 và xử lý thông điệp là mã hóa MIME.
Phân tích cú pháp các tiêu đề Content-Type và Content-Transfer-Encoding, bao gồm tất cả các tham số.
Giải mã base64 và quoted-printable mã hóa truyền nội dung.
Xử lý tất cả các loại multipart — tối thiểu multipart/mixed, multipart/alternative, multipart/digest, và multipart/parallel. Các kiểu con multipart không xác định phải được xử lý như multipart/mixed.
Xử lý message/rfc822 — hiển thị thông điệp được đóng gói hoặc ít nhất cung cấp nó để lưu.
Xử lý các loại nội dung không được nhận dạng một cách khéo léo — cung cấp tùy chọn lưu phần nội dung dưới dạng tập tin thay vì gặp sự cố hoặc loại bỏ nó im lặng. Các loại không được nhận dạng phải được xử lý như application/octet-stream.
Giải mã các từ được mã hóa RFC 2047 trong các trường tiêu đề.
Xử lý tham số charset trên các loại văn bản, hỗ trợ ít nhất US-ASCII và ISO-8859-1, và lý tưởng nhất là UTF-8.

Nguyên Tắc Tính Vững Chắc

RFC 2049 củng cố Luật Postel cho MIME: khắt khe về những gì bạn gửi, tự do về những gì bạn chấp nhận. Một bộ nhận tuân thủ phải cố gắng hết sức để hiển thị ngay cả những thông điệp MIME hơi sai lệch thay vì từ chối chúng hoàn toàn.

Các Chi Tiết Kỹ Thuật Chính

Ví Dụ Chuẩn

RFC 2049 bao gồm các ví dụ được thực hiện của các thông điệp MIME. Đây là mô hình cho một thông điệp multipart/alternative được định dạng tốt với cả văn bản thuần túy và HTML:

MIME-Version: 1.0
From: sender@example.com
To: recipient@example.com
Subject: MIME conformance test
Content-Type: multipart/alternative; boundary="boundary42"

--boundary42
Content-Type: text/plain; charset=us-ascii

This is the plain text version.

--boundary42
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><p>This is the <strong>HTML</strong> version.</p></body></html>

--boundary42--

Xử Lý Các Loại Không Xác Định

Một yêu cầu tuân thủ chính: khi một tác nhân nhận gặp phải Content-Type mà nó không hiểu, nó phải xử lý nó như application/octet-stream và cung cấp tùy chọn lưu. Quy tắc này đảm bảo khả năng tương thích về phía trước — các loại phương tiện mới có thể được định nghĩa mà không làm hỏng các máy khách hiện tại.

; Unknown type encountered by a client
Content-Type: application/vnd.custom-format
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="data.custom"

; Conformant client treats this as application/octet-stream
; and offers the user a "Save As" dialog

Các Kiểu Con Multipart Không Xác Định

Tương tự như vậy, các kiểu con multipart không được xác định phải được xử lý như multipart/mixed. Điều này có nghĩa là máy khách hiển thị từng phần tuần tự. Ví dụ: multipart/report (được định nghĩa sau trong RFC 3462) vẫn sẽ hiển thị đúng trong các máy khách cũ hơn xử lý nó như hỗn hợp.

Hỗ Trợ Ký Tự Tối Thiểu

Các triển khai tuân thủ phải hỗ trợ ít nhất:

US-ASCII — đường cơ sở
ISO-8859-1 — các ký tự Tây Âu (Latin-1)

Trên thực tế, bất kỳ triển khai hiện đại nào phải hỗ trợ UTF-8. Không làm như vậy vào năm 2024 trở lên là một sai sót tuân thủ về tinh thần, ngay cả khi thông số năm 1996 không yêu cầu nó.

Ranh Giới MIME/Không MIME

Các thông điệp không có tiêu đề MIME-Version: 1.0 được coi là văn bản ASCII thuần túy trước MIME, bất kể liệu chúng có chứa các tiêu đề Content-Type hay không. Tiêu đề MIME-Version là người kiểm soát: nếu không có nó, xử lý MIME không được kích hoạt.

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

Gặp sự cố với Content-Types không xác định. Thông số là rõ ràng: xử lý các loại không xác định như application/octet-stream. Các thư viện ném ngoại lệ trên các loại không xác định không tuân thủ và sẽ bị hỏng khi các loại phương tiện mới được đăng ký.
Coi các kiểu con multipart không xác định là lỗi. Chúng phải được xử lý như multipart/mixed. Một lỗi phổ biến là từ chối hoặc bỏ qua multipart/report, multipart/signed hoặc các loại mở rộng khác.
Bỏ qua charset trên các loại text/*. Nội dung văn bản mà không có khai báo bộ ký tự mặc định là US-ASCII. Hiển thị nó dưới dạng UTF-8 có thể hoạt động cho nội dung ASCII nhưng sẽ tạo ra đầu ra lộn xộn cho các thông điệp ISO-8859-1 kế thừa.
Loại bỏ MIME-Version khỏi các thông điệp được chuyển tiếp. Khi chuyển tiếp hoặc gửi lại, tiêu đề MIME-Version phải được bảo tồn. Nếu không có nó, máy khách nhận có thể không xử lý cấu trúc MIME cách nào cả.
Giải mã base64/QP không đầy đủ. Cả hai bộ giải mã phải xử lý các trường hợp cạnh: padding base64, các ngắt dòng mềm QP (=\r\n) và khoảng trắng ở cuối. Các bộ giải mã không đầy đủ tạo ra đầu ra bị hỏng cho các thông điệp hợp pháp.
Không cung cấp tùy chọn lưu cho các phần không thể hiển thị. Một máy khách tuân thủ phải để người dùng lưu bất kỳ phần nội dung nào, ngay cả khi nó không thể hiển thị. Loại bỏ im lặng các phần vi phạm thông số và mất dữ liệu.

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

Cấu trúc MIME tuân thủ là đường cơ sở khả năng gửi. Các thông điệp không tuân thủ — thiếu MIME-Version, ranh giới multipart bị hỏng, mã hóa không chính xác — là dấu hiệu của các công cụ spam. Bộ lọc spam sử dụng sự tuân thủ MIME làm tín hiệu chất lượng.
Bao gồm cả text/plain và text/html. Các ví dụ của RFC 2049 minh họa multipart/alternative với cả hai định dạng. Đây không chỉ là thực hành tốt; nhiều bộ lọc spam phạt các thông điệp chỉ HTML. Phần text/plain phải có nội dung có ý nghĩa, không chỉ "Xem email này trong trình duyệt của bạn."
Content-Transfer-Encoding hợp lệ ngăn chặn tính não. Một thông điệp khai báo quoted-printable nhưng chứa dữ liệu 8-bit thô sẽ bị làm hỏng bởi các cổng SMTP 7-bit. Điều này gây ra lỗi hiển thị ở người nhận, ngay cả khi thông điệp đạt hộp thư đến.
Khai báo bộ ký tự chính xác ngăn chặn mojibake. Khai báo charset=us-ascii cho nội dung UTF-8 làm cho các ký tự có dấu không thể đọc được. Người nhận có thể báo cáo thông điệp dưới dạng spam thay vì cố gắng giải mã nó.
MIME được định dạng tốt cải thiện hiển thị trên các máy khách. Một thông điệp tuân thủ MIME hiển thị chính xác trong Gmail, Outlook, Apple Mail, Thunderbird và các máy khách di động. Các thông điệp không tuân thủ có thể hiển thị ở một máy khách nhưng bị hỏng ở máy khác, gây ra khiếu nại và hủy đăng ký.