← RFC Reference

RFC 6532 – Tiêu đề Email Quốc tế hóa

Tại sao RFC này tồn tại

Định dạng email gốc (RFC 5322) giới hạn các trường tiêu đề chỉ sử dụng ký tự US-ASCII. Để bao gồm văn bản không phải ASCII trong các tiêu đề như Subject, tên hiển thị From, hoặc nhận xét địa chỉ, người gửi phải sử dụng RFC 2047 encoded words — một lược đồ phức tạp mã hóa Base64 hoặc Q-encode văn bản và bao gọi nó trong các ký tự đánh dấu =?charset?encoding?...?=.

Hệ thống này hoạt động nhưng tạo ra các tiêu đề không thể đọc được ở dạng thô, khó thực hiện chính xác, và bị giới hạn nơi chúng có thể xuất hiện. Ví dụ, các encoded words của RFC 2047 không thể được sử dụng bên trong phần local-part của một địa chỉ email.

RFC 6532 cập nhật RFC 5322 để cho phép UTF-8 trực tiếp trong các tiêu đề email. Kết hợp với RFC 6531 (SMTPUTF8 cho phần envelope SMTP), điều này cho phép email hoàn toàn quốc tế hóa nơi các địa chỉ, tên hiển thị, chủ đề, và các tiêu đề khác có thể sử dụng tập lệnh gốc mà không cần các cách thay thế mã hóa.

Cách hoạt động

1. Thông báo được truyền tải qua SMTP với phần mở rộng SMTPUTF8 (RFC 6531), báo hiệu rằng thông báo sử dụng nội dung quốc tế hóa.
2. Các trường tiêu đề có thể chứa các octets UTF-8 thô ở bất kỳ nơi nào mà RFC 5322 cho phép văn bản.
3. Các địa chỉ email trong tiêu đề (From, To, Cc, Reply-To) có thể chứa các ký tự UTF-8 trong phần local-part và phần domain.
4. Content-Type cho khối tiêu đề thông báo được ngầm định là message/global (được định nghĩa trong RFC 6532) thay vì message/rfc822 truyền thống.
5. Các ứng dụng email nhận hỗ trợ RFC 6532 hiển thị các tiêu đề một cách tự nhiên. Các ứng dụng không hỗ trợ có thể hiển thị các byte UTF-8 thô hoặc không thể phân tích cú pháp các tiêu đề.

Ví dụ về tiêu đề

Các tiêu đề được mã hóa RFC 2047 truyền thống so với các tiêu đề RFC 6532:

Một thông báo hoàn toàn quốc tế hóa:

Các chi tiết kỹ thuật chính

message/global so với message/rfc822

RFC 6532 giới thiệu một loại MIME mới: message/global. Điều này hoạt động giống với message/rfc822 nhưng báo hiệu rằng thông báo có thể chứa UTF-8 trong các tiêu đề. Khi một thông báo được truyền tải với SMTPUTF8, các thông báo được đính kèm và các thông báo được chuyển tiếp nên sử dụng message/global thay vì message/rfc822:

Nơi UTF-8 được phép

RFC 6532 cho phép UTF-8 ở tất cả các vị trí trường tiêu đề nơi RFC 5322 cho phép văn bản:

• Tên hiển thị: From: 田太郎 <taro@example.jp>
• Địa chỉ local-parts: To: <田太郎@example.jp>
• Tên miền: Cc: <user@例.jp>
• Các trường không có cấu trúc: Subject: 会議の確認
• Nhận xét: From: user@example.com (山田太郎)

Những cân nhắc về ký DKIM

Các chữ ký DKIM bao gồm các tiêu đề cụ thể. Khi những tiêu đề đó chứa UTF-8 thô, quá trình ký và xác minh phải xử lý các byte một cách chính xác. Thẻ h= của DKIM liệt kê các tiêu đề cần ký, và tính chính tắc được áp dụng cho các byte UTF-8 thô. Cả người gửi và người xác minh phải xử lý cùng một chuỗi byte để các chữ ký phù hợp.

Khả năng tương thích ngược

Các thông báo RFC 6532 không tương thích ngược với các hệ thống email chỉ hiểu RFC 5322. Một máy chủ hoặc ứng dụng khách nhận được thông báo message/global nhưng không hỗ trợ RFC 6532 có thể:

• Hiển thị các byte UTF-8 thô (hầu hết các ứng dụng hiện đại xử lý hợp lý)
• Không thể phân tích cú pháp các tiêu đề địa chỉ chứa các ký tự non-ASCII
• Phá vỡ xác minh DKIM nếu cách thực hiện không xử lý các tiêu đề UTF-8

Những lỗi thường gặp

• Sử dụng tiêu đề RFC 6532 mà không có SMTPUTF8 trong phần envelope. Nếu phiên SMTP không sử dụng tham số SMTPUTF8, thông báo phải sử dụng các encoded words RFC 2047 cho nội dung tiêu đề non-ASCII. Các tiêu đề RFC 6532 chỉ có giá trị khi được gửi qua RFC 6531.
• Trộn RFC 2047 và UTF-8 thô trong cùng một tiêu đề. Chọn một cách tiếp cận cho mỗi thông báo. Nếu bạn gửi qua SMTPUTF8, hãy sử dụng UTF-8 thô. Nếu không, hãy sử dụng RFC 2047 trong suốt. Trộn chúng tạo ra sự mơ hồ trong phân tích.
• Sử dụng message/rfc822 cho các tệp đính kèm quốc tế hóa. Khi chuyển tiếp hoặc đính kèm một thông báo chứa các tiêu đề UTF-8, hãy sử dụng message/global làm loại MIME, không phải message/rfc822.
• Bỏ qua chuẩn hóa Unicode. Cùng một ký tự trực quan có thể có nhiều biểu diễn byte trong Unicode. Sử dụng chuẩn hóa NFC một cách nhất quán cho các địa chỉ email và nội dung tiêu đề để ngăn chặn các lỗi khớp và xác minh.
• Giả định rằng tất cả các ứng dụng email hiển thị UTF-8 một cách chính xác. Mặc dù các ứng dụng hiện đại xử lý UTF-8 tốt, một số ứng dụng cũ hơn hoặc nhúng có thể không. Đối với email giao dịch quan trọng, hãy xem xét liệu khán giả của bạn có bao gồm người dùng trên các hệ thống cũ.
• Phá vỡ DKIM bằng cách sửa đổi các tiêu đề UTF-8 trong quá trình truyền tải. Một số hệ thống xử lý email chuẩn hóa hoặc mã hóa lại văn bản UTF-8. Bất kỳ sửa đổi nào đối với tiêu đề được ký DKIM, thậm chí thay đổi dạng chuẩn hóa Unicode, sẽ làm mất hiệu lực chữ ký.

Tác động đến khả năng gửi

• Hiển thị tốt hơn cho những người nhận quốc tế. Các tên hiển thị và chủ đề tập lệnh gốc trông chuyên nghiệp và đáng tin cậy. Các ký tự được mã hóa trong các tiêu đề có thể gây nhầm lẫn cho người nhận và kích hoạt sự nghi ngờ.
• DKIM phải xử lý UTF-8 một cách chính xác. Nếu cách thực hiện DKIM của bạn ký các tiêu đề UTF-8 và người xác minh xử lý chúng khác nhau (chuẩn hóa khác nhau, mã hóa khác nhau), chữ ký sẽ không có hiệu lực. Điều này trực tiếp ảnh hưởng đến căn chỉnh DMARC và khả năng gửi.
• Hỗ trợ nhà cung cấp ngày càng tăng. Gmail, Outlook.com, và các nhà cung cấp lớn khác hỗ trợ các tiêu đề RFC 6532. Các thông báo có các tiêu đề UTF-8 sạch được hiển thị chính xác bởi các nhà cung cấp này.
• Bắt buộc đối với các địa chỉ hoàn toàn quốc tế hóa. Bạn không thể có một địa chỉ email quốc tế hóa mà không có các tiêu đề RFC 6532. Khi áp dụng EAI tăng lên, hỗ trợ RFC này trở thành điều cần thiết để tiếp cận người dùng toàn cầu.
• Chiến lược dự phòng quan trọng. Để có khả năng gửi tối đa, hãy tạo cả phiên bản message/global (cho các máy chủ có khả năng SMTPUTF8) và phiên bản hạ cấp RFC 2047 (cho những phiên bản khác). Cơ sở hạ tầng gửi của bạn nên lựa chọn dựa trên khả năng của người nhận.

Related RFCs