← RFC Reference

RFC 6854: Cú Pháp Nhóm trong Các Trường Tiêu Đề From và Sender

Tại sao tính năng này tồn tại

RFC 5322 yêu cầu header From phải chứa một hoặc nhiều địa chỉ hộp thư. Nhưng một số thư thực sự không có tác giả con người duy nhất:

• Thư tự động từ hệ thống — cảnh báo giám sát, thông báo xây dựng, báo cáo theo lịch. Không có người nào viết những thư này.
• Tóm tắt danh sách gửi thư — một tóm tắt tập hợp thư từ nhiều tác giả. Địa chỉ "From" là ai?
• Tài liệu tác giả theo nhóm — thư được soạn thảo cộng tác bởi một nhóm.
• Địa chỉ noreply — một số tổ chức muốn chỉ ra rằng không mong đợi phản hồi, mà không tiết lộ địa chỉ thực.

RFC 6854 cập nhật RFC 5322 để cho phép cú pháp nhóm trong các header From và Sender. Cú pháp nhóm có thể chứa không hoặc nhiều địa chỉ hộp thư, có nghĩa là bạn có thể có header From với tên mô tả nhưng không có địa chỉ thực bên trong nó.

Cách hoạt động

Cơ bản về cú pháp nhóm

Cú pháp nhóm đã được định nghĩa trong RFC 5322 cho các header như To và Cc. Nó trông như thế này:

; Cú pháp nhóm: display-name ":" [mailbox-list] ";"

; Nhóm có thành viên (đã được cho phép trong To/Cc)
To: Engineering Team: alice@example.com, bob@example.com;

; Nhóm trống — không có địa chỉ (đổi mới chính của RFC 6854)
From: Engineering Team:;

Khả năng quan trọng mới là nhóm trống trong From: tên hiển thị theo sau là :; không có địa chỉ nào giữa dấu hai chấm và dấu chấm phẩy.

Yêu cầu khi sử dụng cú pháp nhóm trong From

RFC 6854 đặt ra các điều kiện nghiêm ngặt:

1. Header Sender là bắt buộc. Khi trường From sử dụng cú pháp nhóm (đặc biệt là các nhóm trống), thư phải bao gồm header Sender với địa chỉ hộp thư hợp lệ. Điều này đảm bảo luôn có một địa chỉ chịu trách nhiệm cho thư.
2. Địa chỉ Sender phải là hộp thư thực, có thể gửi được. Nó phải có khả năng nhận phản hồi và thư bị trả lại.
3. Sử dụng một cách hạn chế. RFC rõ ràng lưu ý rằng đây là cho các trường hợp không có tác giả duy nhất nào có thể được xác định. Thư email từ người này sang người khác thông thường nên tiếp tục sử dụng cú pháp hộp thư tiêu chuẩn trong From.

Ví dụ thực tế

; Cảnh báo giám sát tự động — không có tác giả con người
From: Monitoring System:;
Sender: noc@example.com
To: ops-team@example.com
Subject: [ALERT] Database connection pool exhausted

; Tóm tắt danh sách gửi thư — nhiều tác giả được tập hợp
From: Dev List Digest:;
Sender: dev-list-owner@lists.example.org
To: dev-list@lists.example.org
Subject: Dev List Digest, Vol 42, Issue 7

; Nhóm với một thành viên — tác giả được đặt tên thay mặt cho một nhóm
From: Security Team: security-lead@example.com;
To: all-staff@example.com
Subject: Mandatory password rotation notice

Khác biệt với From tiêu chuẩn

Chi tiết kỹ thuật chính

Tương tác với DKIM

DKIM ký header From. Khi From chứa cú pháp nhóm, DKIM hoạt động trên giá trị header theo nghĩa đen. Miền d= trong chữ ký DKIM không cần khớp với địa chỉ trong nhóm From (vì có thể không có). Thay vào đó, căn chỉnh DKIM cho DMARC quay lại header Sender hoặc người gửi bao lấp.

Tương tác với DMARC

Căn chỉnh DMARC yêu cầu miền From khớp với miền d= của DKIM hoặc miền người gửi bao lấp được xác thực SPF. Với một nhóm trống trong From, không có miền nào để căn chỉnh. Trong thực tế, điều này có nghĩa là:

• DMARC không thể đánh giá căn chỉnh cho các header From có nhóm trống.
• Hầu hết các triển khai DMARC coi đây là kết quả không áp dụng được.
• Header Sender hoặc người gửi bao lấp cung cấp neo xác thực thực tế.

Điều này làm cho các header From có nhóm trống không phổ biến trong thực tế cho thư điện tử đối mặt với internet, vì DMARC hiện được triển khai rộng rãi.

Hành vi hiển thị của client

Các client thư xử lý cú pháp nhóm trong From không nhất quán:

• Gmail: Hiển thị địa chỉ Sender là From, bỏ qua tên hiển thị nhóm.
• Outlook: Có thể hiển thị tên nhóm hoặc địa chỉ Sender, tùy thuộc vào phiên bản.
• Apple Mail: Thường hiển thị địa chỉ Sender.
• Thunderbird: Hiển thị tên hiển thị nhóm với địa chỉ Sender trong dấu ngoặc đơn.

Hiển thị không nhất quán là hạn chế thực tế chính của tính năng này.

Cập nhật ngữ pháp ABNF

RFC 6854 cập nhật ngữ pháp RFC 5322 cho các trường from và sender:

; RFC 5322 gốc
from = "From:" mailbox-list CRLF

; Cập nhật RFC 6854
from = "From:" (mailbox-list / address-list) CRLF

; address-list cho phép cú pháp nhóm
; group = display-name ":" [group-list] ";"

Những sai lầm phổ biến

• Sử dụng From có nhóm trống mà không có header Sender. RFC 6854 yêu cầu header Sender khi From sử dụng cú pháp nhóm mà không có địa chỉ hộp thư. Không có Sender, không có địa chỉ chịu trách nhiệm cho thư bị trả lại hoặc phản hồi, và các trình phân tích cú pháp nghiêm ngặt sẽ từ chối thư.
• Mong đợi kết xuất client nhất quán. Hầu hết các client thư không được thiết kế cho cú pháp nhóm trong From. Kiểm tra trên Gmail, Outlook và Apple Mail trước khi triển khai. Hiển thị có thể gây nhầm lẫn cho người nhận.
• Sử dụng cú pháp này cho thư tiếp thị hoặc giao dịch đối mặt với internet. Các vấn đề căn chỉnh DMARC làm cho From có nhóm trống không thực tế cho thư cần vượt qua kiểm tra xác thực tại các nhà cung cấp lớn. Tiếp tục sử dụng hộp thư From tiêu chuẩn cho tính gửi được.
• Quên bộ chấm phẩy kết thúc. Cú pháp nhóm yêu cầu ; đóng. Không có nó, header là sai định dạng: From: Team: là không hợp lệ; From: Team:; là đúng.
• Nhầm lẫn cú pháp nhóm với tên hiển thị. From: Team <team@example.com> là hộp thư với tên hiển thị. From: Team:; là một nhóm trống. Chúng là những cấu trúc hoàn toàn khác nhau với ngữ nghĩa và yêu cầu khác nhau.
• Sử dụng cú pháp này khi địa chỉ noreply đủ. Đối với hầu hết các thư tự động, From: noreply@example.com đơn giản hơn, tương thích hơn và được hiểu rõ hơn bởi người nhận và bộ lọc spam hơn là cú pháp nhóm.

Ảnh hưởng gửi được

• From có nhóm trống phá vỡ căn chỉnh DMARC. Vì không có miền trong địa chỉ From, DMARC không có gì để căn chỉnh. Các thư dựa vào cú pháp này sẽ không vượt qua kiểm tra DMARC tại hầu hết các máy nhận, dẫn đến từ chối hoặc kiểm tra cách ly nếu miền người gửi có chính sách DMARC nghiêm ngặt.
• Bộ lọc spam có thể gắn cờ cú pháp From không quen. Cú pháp nhóm trong From rất hiếm. Các bộ lọc spam được huấn luyện trên các mẫu thư bình thường có thể coi nó là bất thường, làm tăng điểm spam.
• Ưu tiên các địa chỉ From tiêu chuẩn cho tất cả thư bên ngoài. Sử dụng hộp thư thực như noreply@example.com hoặc notifications@example.com. Điều này tương thích phổ quát, vượt qua DMARC và kết xuất chính xác trong tất cả các client.
• Cú pháp nhóm thích hợp cho môi trường nội bộ hoặc được kiểm soát. Trong một tổ chức nơi bạn kiểm soát cơ sở hạ tầng thư và client, cú pháp nhóm có thể đại diện có ý nghĩa cho tác giả nhóm hoặc hệ thống. Đối với thư điện tử đối mặt với internet, những lợi ích trả đổi gửi được không đáng giá.
• Luôn bao gồm header Sender hợp lệ. Ngay cả khi gửi hoạt động mà không cần nó trong các bài kiểm tra của bạn, header Sender là dự phòng cho thư bị trả lại, phản hồi và xác thực. Bỏ qua nó có nguy cơ gây ra lỗi im lặng ở quy mô lớn.

Related RFCs