← RFC Reference

RFC 3462: Loại Nội dung Multipart/Report

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

Khi framework DSN (Delivery Status Notification) được tạo ra vào giữa những năm 1990, các tác giả cần một MIME container có thể mang cả nội dung có thể đọc được bởi con người và có thể đọc được bởi máy trong cùng một thông điệp. multipart/mixed thông thường sẽ hoạt động về mặt cấu trúc, nhưng nó không cung cấp tín hiệu ngữ nghĩa rằng thông điệp là một báo cáo tự động với định dạng nội bộ cụ thể.

multipart/report giải quyết điều này bằng cách:

• Báo hiệu cho các mail client rằng thông điệp là một báo cáo tự động, cho phép xử lý giao diện đặc biệt (nhiều client hiển thị bounces khác với email thông thường)
• Bao gồm tham số report-type để các trình phân tích cú pháp biết định dạng có thể đọc được bởi máy nào cần chờ bên trong
• Xác định thứ tự phần chặt chẽ: có thể đọc được bởi con người trước tiên, có thể đọc được bởi máy thứ hai, thông điệp gốc thứ ba

RFC 3462 là bản sửa đổi thứ hai của thông số này (sau RFC 1892). Nó sau đó bị lỗi thời bởi RFC 6522, giới hạn ngôn ngữ và cập nhật đăng ký IANA. Định dạng dây thực tế không thay đổi — các thông điệp tuân thủ RFC 3462 cũng tuân thủ RFC 6522.

Cách Nó Hoạt Động

Loại nội dung multipart/report hoạt động như bất kỳ MIME multipart nào, với các ràng buộc được thêm vào:

Khai Báo Content-Type

Content-Type: multipart/report; report-type=delivery-status;
    boundary="REPORT-BOUNDARY"

Tham số report-type cho người nhận biết loại báo cáo này là gì. Tham số boundary tách các phần MIME, giống như bất kỳ thông điệp multipart nào.

Cấu Trúc Ba Phần

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

; Phần 1: Tóm tắt có thể đọc được bởi con người
Gửi đến user@example.org không thành công vĩnh viễn.
Hộp thư người nhận không tồn tại.

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

; Phần 2: Báo cáo có thể đọc được bởi máy
Reporting-MTA: dns; mx.example.com

Final-Recipient: rfc822;user@example.org
Action: failed
Status: 5.1.1

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

; Phần 3: Tiêu đề thông điệp gốc (tùy chọn)
From: sender@example.com
To: user@example.org
Subject: Hello
Message-ID: <msg-001@example.com>

--REPORT-BOUNDARY--

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

Các Loại Báo Cáo Được Xác Định Theo Thời Gian

Khi RFC 3462 được xuất bản, chỉ delivery-status tồn tại. Các RFC sau đó đã thêm nhiều loại báo cáo khác đều sử dụng container multipart/report giống nhau:

Phần Tối Thiểu Được Yêu Cầu

RFC 3462 yêu cầu ít nhất hai phần: tóm tắt có thể đọc được bởi con người và báo cáo có thể đọc được bởi máy. Phần thứ ba (thông điệp gốc) là tùy chọn nhưng được khuyến khích mạnh mẽ cho DSN, vì nó cho phép người gửi xác định thông điệp nào bị bounce.

Mối Quan Hệ Với RFC 6522

RFC 6522 lỗi thời tài liệu này. Những thay đổi là biên tập, không phải hành vi:

• Tham số report-type được đánh dấu rõ ràng là bắt buộc (3462 là không rõ ràng)
• Mẫu đăng ký IANA được cập nhật để tuân thủ các tiêu chuẩn hiện tại
• Hỗ trợ cho các loại thông điệp quốc tế hóa (message/global) đã được thêm

Nếu mã của bạn đã xử lý RFC 3462 một cách chính xác, nó cũng xử lý RFC 6522. Định dạng dây không thay đổi.

Lỗi Phổ Biến

• Coi phần có thể đọc được bởi con người là có thẩm quyền. Phần đầu tiên chỉ dành cho hiển thị. Các hệ thống tự động phải phân tích cú pháp phần thứ hai (có thể đọc được bởi máy). Văn bản có thể đọc được bởi con người có thể không khớp với dữ liệu có cấu trúc.
• Giả định chỉ ba phần. Mặc dù hầu hết các báo cáo có chính xác ba phần, thông số kỹ thuật cho phép hai phần (không có thông điệp gốc). Trình phân tích cú pháp của bạn không nên thất bại khi phần thứ ba bị thiếu.
• Bỏ qua multipart/report hoàn toàn. Một số bộ xử lý bounce cố gắng phân tích cú pháp tất cả các thông điệp bounce dưới dạng văn bản tự do. Điều này hoạt động kém. Luôn kiểm tra multipart/report trước tiên và sử dụng dữ liệu có cấu trúc khi có sẵn.
• Không kiểm tra report-type. Một multipart/report với report-type=feedback-report là một khiếu nại spam, không phải một bounce. Coi nó là một bounce (và xóa địa chỉ khỏi danh sách của bạn) là sai — địa chỉ là hợp lệ, người nhận chỉ không muốn email của bạn.
• Tạo báo cáo mà không có phần thứ ba. Mặc dù về mặt kỹ thuật hợp lệ, việc bỏ qua tiêu đề thông điệp gốc sẽ làm cho người gửi rất khó xác định thông điệp nào kích hoạt báo cáo. Luôn bao gồm ít nhất các tiêu đề.

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

• Tất cả các luồng phản hồi email tự động đi qua định dạng này. Dù là một bounce, một khiếu nại spam, một biên lai đã đọc hay một báo cáo TLS, container bên ngoài là multipart/report. Hiểu định dạng này là điều kiện tiên quyết để xử lý bất kỳ điều nào trong số chúng.
• Phân loại bounce chính xác bắt đầu ở đây. Bằng cách kiểm tra report-type trước tiên, hệ thống của bạn có thể định tuyến các thông điệp delivery-status đến bộ xử lý bounce của bạn và các thông điệp feedback-report đến trình xử lý khiếu nại của bạn — hai quy trình công việc hoàn toàn khác nhau.
• Hiển thị mail client. Nhiều mail client nhận ra multipart/report và kết xuất nó đặc biệt (ví dụ: hiển thị biểu ngữ "gửi không thành công"). Tạo các báo cáo được định dạng tốt sẽ cải thiện trải nghiệm người dùng khi máy chủ của bạn gửi bounces.
• Tương quan Message-ID. Phần thứ ba (thông điệp gốc hoặc tiêu đề) là cách bạn khớp một bounce lại với thông điệp đã gây ra nó. Nếu không có nó, bạn đang đoán dựa vào địa chỉ người nhận một mình, điều này không đáng tin cậy với chuyển tiếp và bí danh.

Related RFCs