← RFC Reference

RFC 6522: Loại Phương Tiện Multipart/Report (Được Cập Nhật)

Tại Sao Nó Tồn Tại

Email tạo ra nhiều loại báo cáo tự động: thông báo bounce (RFC 3464), khiếu nại spam (RFC 5965), báo cáo lỗi xác thực (RFC 6591), và báo cáo lỗi TLS (RFC 8460). Tất cả các loại này cần một định dạng container chung có thể chứa cả bản tóm tắt có thể đọc được bởi con người và báo cáo có thể phân tích bằng máy.

multipart/report là container đó. Nó được định nghĩa ban đầu trong RFC 3462, nó cũng đã cập nhật RFC 1892. RFC 6522 là phiên bản hiện tại, đưa thông số kỹ thuật này phù hợp với các quy trình đăng ký MIME hiện đại và làm rõ những sự mơ hồ từ các bản dự thảo trước đó.

Những thay đổi chính từ RFC 3462 sang 6522:

• Cập nhật đăng ký loại MIME để tuân theo định dạng mẫu IANA hiện tại
• Làm rõ rằng tham số report-type là bắt buộc, không phải tùy chọn
• Tightened thông số kỹ thuật để loại bỏ những sự mơ hồ về thứ tự phần
• Căn chỉnh với khung MIME được cập nhật trong RFC 6838

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

Một tin nhắn multipart/report là một tin nhắn MIME multipart có tham số report-type bắt buộc xác định loại báo cáo bên trong. Nó chứa hai hoặc ba phần MIME theo thứ tự cụ thể:

1. Phần có thể đọc được bởi con người (text/plain hoặc text/html) — bản tóm tắt cho những người mở tin nhắn trong ứng dụng mail.
2. Báo cáo có thể đọc được bằng máy — dữ liệu có cấu trúc. Loại nội dung phụ thuộc vào report-type:
   • delivery-status → message/delivery-status (RFC 3464)
   • feedback-report → message/feedback-report (RFC 5965)
   • tlsrpt → application/tlsrpt+json (RFC 8460)
3. Tin nhắn gốc (tùy chọn) — message/rfc822 (tin nhắn đầy đủ) hoặc text/rfc822-headers (chỉ tiêu đề) của tin nhắn đã kích hoạt báo cáo.

Ví Dụ Cấu Trúc: DSN Bounce

From: mailer-daemon@mail.example.org
To: sender@example.com
Subject: Delivery Status Notification (Failure)
MIME-Version: 1.0
Content-Type: multipart/report; report-type=delivery-status;
    boundary="REPORT-BOUNDARY-001"

--REPORT-BOUNDARY-001
Content-Type: text/plain

Your message to user@example.org could not be delivered.
The mailbox does not exist.

--REPORT-BOUNDARY-001
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue, 10 Mar 2026 14:22:00 -0500

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1
Diagnostic-Code: smtp; 550 5.1.1 Mailbox not found

--REPORT-BOUNDARY-001
Content-Type: text/rfc822-headers

From: sender@example.com
To: user@example.org
Subject: Invoice #1234
Message-ID: <inv-1234@example.com>

--REPORT-BOUNDARY-001--

Ví Dụ Cấu Trúc: ARF Complaint

Content-Type: multipart/report; report-type=feedback-report;
    boundary="ARF-BOUNDARY-001"

--ARF-BOUNDARY-001
Content-Type: text/plain

This is a spam complaint for a message from 203.0.113.10.

--ARF-BOUNDARY-001
Content-Type: message/feedback-report

Feedback-Type: abuse
User-Agent: FBL/1.0
Version: 1
Source-IP: 203.0.113.10

--ARF-BOUNDARY-001
Content-Type: message/rfc822

[original message]

--ARF-BOUNDARY-001--

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

Tham Số report-type

Tham số report-type trên tiêu đề Content-Type là bắt buộc và cho các trình phân tích cú pháp biết loại dữ liệu có thể đọc được bằng máy nào để mong đợi trong phần MIME thứ hai:

Quy Tắc Thứ Tự Phần

• Phần đầu tiên luôn phải có thể đọc được bởi con người (text/plain hoặc tương tự).
• Phần thứ hai phải là báo cáo có thể đọc được bằng máy có loại nội dung phù hợp với report-type.
• Phần thứ ba tùy chọn chứa tin nhắn gốc hoặc tiêu đề của nó. Nó phải sử dụng message/rfc822, text/rfc822-headers, hoặc message/global (cho những tin nhắn được quốc tế hóa).

Quốc Tế Hóa

RFC 6522 bổ sung hỗ trợ cho message/global và message/global-headers như các giải pháp thay thế cho phần thứ ba, phù hợp với các địa chỉ email được quốc tế hóa và tiêu đề theo RFC 6531/6532.

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

• Bỏ qua tham số report-type. Không có report-type, các trình phân tích cú pháp không thể xác định phần MIME thứ hai chứa gì. RFC 6522 làm cho tham số này bắt buộc; luôn luôn bao gồm nó.
• Thứ tự phần sai. Một số cách triển khai đặt phần có thể đọc được bằng máy trước. Phần có thể đọc được bởi con người phải đến trước để các ứng dụng mail không hiểu loại báo cáo vẫn có thể hiển thị một cái gì đó hữu ích.
• Phân tích cú pháp chỉ theo Content-Type. Đừng cố gắng phát hiện loại báo cáo bằng cách quét Content-Type của phần thứ hai. Hãy sử dụng tham số report-type trên Content-Type multipart/report bên ngoài — đó là công dụng của nó.
• Coi multipart/report như multipart/mixed. Mặc dù về mặt cấu trúc tương tự, multipart/report có thứ tự phần và ngữ nghĩa nghiêm ngặt. Một trình phân tích MIME chung có thể hiển thị nó, nhưng một bộ xử lý báo cáo phải tôn trọng cấu trúc được xác định.
• Nhầm lẫn RFC 3462 và RFC 6522. Chúng định nghĩa cùng một loại nội dung. RFC 6522 lỗi thời hóa 3462. Nếu bạn thấy các tham chiếu đến RFC 3462 trong mã hiện có, hành vi là tương đương — nhưng trích dẫn 6522 trong các triển khai mới.

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

• Nền tảng của tất cả các báo cáo email. Mọi DSN, khiếu nại ARF, báo cáo tổng hợp DMARC, và báo cáo lỗi TLS đều sử dụng multipart/report. Nếu trình phân tích cú pháp của bạn không thể xử lý container này, bạn không thể xử lý bất kỳ phản hồi email tự động nào.
• Xử lý bounce phụ thuộc vào phân tích cú pháp chính xác. Bộ xử lý bounce của bạn trước tiên phải nhận biết multipart/report, sau đó kiểm tra report-type=delivery-status, sau đó trích xuất phần message/delivery-status. Sai bất kỳ bước nào đều có nghĩa là bounces bị bỏ qua và vệ sinh danh sách bị suy giảm.
• Xử lý vòng lặp khiếu nại. Báo cáo vòng lặp phản hồi từ các nhà cung cấp hộp thư sử dụng report-type=feedback-report. Phân tích cú pháp container chính xác là bước đầu tiên để trích xuất dữ liệu khiếu nại và loại bỏ những người nhận.
• Báo cáo TLS. SMTP TLS Reporting cung cấp các tải trọng JSON bên trong multipart/report với report-type=tlsrpt. Những báo cáo này tiết lộ những lỗi thương lượng TLS im lặng ngăn cản thư của bạn được gửi một cách an toàn.

Related RFCs