← RFC Reference

RFC 6377: DKIM và Danh sách Gửi thư

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

DKIM (RFC 6376) ký các tiêu đề email và nội dung thân bằng hàm băm mật mã. Bất kỳ sửa đổi nào sau khi ký đều làm mất hiệu lực chữ ký. Danh sách gửi thư, theo thiết kế, sửa đổi các tin nhắn khi đang chuyển đi. Điều này tạo ra một xung đột cơ bản:

• DKIM muốn các tin nhắn đến chính xác như đã ký.
• Danh sách gửi thư thêm chân trang, thêm "[tên-danh-sách]" vào chủ đề, thêm tiêu đề List-*, viết lại địa chỉ From và bao gói tin nhắn trong bản tóm tắt.

Khi DMARC xuất hiện (yêu cầu căn chỉnh DKIM hoặc SPF), xung đột này trở thành một cuộc khủng hoảng khả năng giao hàng. Các tin nhắn được gửi đến danh sách gửi thư bởi các miền có chính sách DMARC p=reject bắt đầu bị trả lại cho tất cả những người đăng ký danh sách. RFC 6377 được công bố để ghi lại vấn đề và đề xuất các chiến lược giảm thiểu.

Cách hoạt động

Danh sách gửi thư làm gì với các tin nhắn

Một trình quản lý danh sách gửi thư điển hình (Mailman, Sympa, LISTSERV, Google Groups) có thể thực hiện bất kỳ sự kết hợp nào của:

Luồng xác minh chữ ký

; Bước 1: Tác giả gửi tin nhắn được ký DKIM đến danh sách
From: alice@example.com
To: dev-list@lists.example.org
Subject: Proposed API change
DKIM-Signature: d=example.com; h=from:to:subject; ...

; Bước 2: Phần mềm danh sách sửa đổi tin nhắn
From: alice@example.com            ← không thay đổi (hoặc viết lại)
To: dev-list@lists.example.org
Subject: [dev] Proposed API change  ← được sửa đổi: đã thêm tiền tố
List-Id: <dev-list.lists.example.org>  ← được thêm
DKIM-Signature: d=example.com; h=from:to:subject; ...

; Thân gốc + chân trang được thêm vào
The body text here...

--
To unsubscribe, visit https://lists.example.org/unsub  ← được thêm

; Bước 3: Máy chủ của người nhận xác minh DKIM
; Kết quả: THẤT BẠI (Chủ đề và thân được sửa đổi sau khi ký)

Thực hành được khuyến nghị cho những người vận hành danh sách

RFC 6377 khuyến nghị rằng danh sách gửi thư giảm thiểu các sửa đổi để bảo tồn chữ ký DKIM:

1. Không sửa đổi tiêu đề Chủ đề. Tránh thêm tiền tố [tên-danh-sách]. Sử dụng tiêu đề List-Id thay vào đó — các ứng dụng email có thể lọc dựa trên nó.
2. Không thêm chân trang vào thân. Sử dụng đóng gói MIME nếu cần nội dung chân trang, hoặc thêm chân trang dưới dạng một phần MIME riêng biệt thay vì thêm vào thân hiện có.
3. Thêm chữ ký DKIM mới. Danh sách sẽ ký tin nhắn được sửa đổi bằng khóa DKIM của riêng nó (d=lists.example.org). Điều này không sửa chữ ký gốc, nhưng nó cung cấp chữ ký hợp lệ từ miền danh sách.
4. Cân nhắc viết lại From để giảm thiểu DMARC. Khi miền của người gửi gốc công bố p=reject, hãy viết lại tiêu đề From thành miền danh sách và đặt người gửi gốc trong Reply-To. Điều này được triển khai rộng rãi dưới dạng "From munging."

Thực hành được khuyến nghị cho những người gửi

1. Sử dụng chính tắc thư giãn. Ký bằng c=relaxed/relaxed thay vì c=simple/simple. Chính tắc thư giãn dung thứ những thay đổi khoảng trắng nhỏ mà một số phần mềm danh sách giới thiệu.
2. Ký chỉ các tiêu đề cần thiết. Thẻ h= sẽ bao gồm các tiêu đề bạn quan tâm (From, Subject, Date, To, Message-ID) nhưng không phải các tiêu đề mà danh sách thường thêm (List-Id, List-Unsubscribe).
3. Sử dụng thẻ độ dài thân l= một cách cẩn thận. Thẻ l= giới hạn bao nhiêu phần của thân được ký, vì vậy chân trang được thêm vào không làm hỏng chữ ký. Tuy nhiên, điều này có những tác động về bảo mật — kẻ tấn công có thể thêm nội dung độc hại bên dưới phần được ký.

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

Sự phức tạp của DMARC

RFC 6377 xuất hiện trước DMARC (RFC 7489), nhưng các vấn đề mà nó mô tả đã trở nên nghiêm trọng hơn nhiều khi DMARC được triển khai. Với DMARC p=reject:

; Miền của tác giả công bố DMARC nghiêm ngặt
_dmarc.example.com TXT "v=DMARC1; p=reject; ..."

; Tin nhắn đi qua danh sách gửi thư, DKIM hỏng
; Máy chủ của người nhận kiểm tra DMARC:
;   - SPF: THẤT BẠI (người gửi phong bì là danh sách, không phải example.com)
;   - DKIM: THẤT BẠI (chữ ký bị hỏng do sửa đổi danh sách)
;   - DMARC: THẤT BẠI → TỪ CHỐI
; Kết quả: tin nhắn bị từ chối cho tất cả những người đăng ký danh sách

Đây là lý do tại sao ARC (RFC 8617) được phát triển — để bảo tồn kết quả xác minh trên các trung gian như danh sách gửi thư.

ARC như giải pháp hiện đại

Giao thức Chuỗi Nhận được Xác minh (ARC) cho phép các trung gian như danh sách gửi thư ghi lại kết quả xác minh gốc trước khi sửa đổi tin nhắn. Máy chủ của người nhận có thể sử dụng chuỗi ARC để khôi phục lại kết quả DKIM/SPF gốc, ngay cả sau khi danh sách đã hỏng chữ ký gốc.

Chiến lược viết lại From

Giảm thiểu DMARC phổ biến nhất cho danh sách gửi thư là viết lại From:

; Tin nhắn gốc
From: Alice Smith <alice@strict-dmarc.com>

; Sau khi danh sách viết lại From
From: Alice Smith via Dev List <dev-list@lists.example.org>
Reply-To: Alice Smith <alice@strict-dmarc.com>

Điều này bảo tồn danh tính của người gửi gốc trong văn bản hiển thị và Reply-To trong khi làm cho miền From khớp với chữ ký DKIM của danh sách.

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

• Sử dụng chính tắc c=simple/simple. Chính tắc đơn giản không hoạt động ngay cả với những thay đổi khoảng trắng tầm thường. Luôn sử dụng c=relaxed/relaxed nếu tin nhắn của bạn có thể đi qua danh sách gửi thư hoặc các trung gian khác.
• Ký quá nhiều tiêu đề. Bao gồm các tiêu đề như List-Id hoặc List-Unsubscribe trong thẻ h= của DKIM đảm bảo thất bại khi danh sách thêm các tiêu đề đó. Ký chỉ các tiêu đề bạn tạo.
• Công bố DMARC p=reject mà không xem xét danh sách. Nếu người dùng của bạn gửi đến danh sách gửi thư, chính sách DMARC từ chối nghiêm ngặt sẽ khiến tin nhắn danh sách của họ bị từ chối cho tất cả những người đăng ký. Cân nhắc p=quarantine hoặc đảm bảo rằng người dùng của bạn hiểu được những hậu quả.
• Những người vận hành danh sách không thêm chữ ký DKIM của riêng họ. Sau khi sửa đổi tin nhắn, danh sách sẽ ký nó bằng khóa của riêng nó. Nếu không có, tin nhắn sẽ đến với không có chữ ký DKIM hợp lệ nào cả.
• Dựa vào độ dài thân l= một cách riêng rẽ. Mặc dù nó có thể bảo tồn chữ ký qua các chân trang được thêm vào, l= đã bị các hướng dẫn thực hành tốt nhất không dùng vì nó cho phép tiêm nội dung bên dưới ranh giới được ký.
• Không triển khai ARC. Phần mềm danh sách hiện đại sẽ triển khai ARC để bảo tồn chuỗi xác minh gốc. Nếu không có ARC, người nhận không có cách nào để biết tin nhắn đã được xác minh ban đầu.

Tác động khả năng giao hàng

• DKIM bị hỏng trên thư danh sách gây ra việc từ chối. Với DMARC p=reject, DKIM bị hỏng có nghĩa là tin nhắn bị từ chối. Những người đăng ký danh sách ngừng nhận thư và người vận hành danh sách bị ngập trong các phiếu trả lại.
• Viết lại From bảo tồn khả năng giao hàng nhưng thay đổi danh tính người gửi. Người nhận thấy địa chỉ danh sách trong From, không phải người gửi gốc. Điều này có thể làm confuse người dùng nhưng là cách đáng tin cậy nhất để đảm bảo giao hàng.
• ARC cải thiện giao hàng cho thư danh sách. Các nhà cung cấp chính (Gmail, Microsoft, Yahoo) tôn trọng các chuỗi ARC. Con dấu ARC hợp lệ từ danh sách có uy tín có thể ghi đè chữ ký DKIM gốc bị hỏng.
• Danh tiếng danh sách quan trọng. Các máy chủ nhận đánh giá danh tiếng miền của danh sách. Danh sách được bảo trì tốt với các thực hành gửi tốt, ký DKIM thích hợp và triển khai ARC sẽ thấy tỷ lệ giao hàng tốt hơn danh sách được vận hành kém.
• Giám sát tỷ lệ phiếu trả lại của bạn từ lưu lượng danh sách. Nếu bạn thấy những sự tăng đột biến trong số phiếu trả lại cho tin nhắn được gửi đến danh sách gửi thư, hãy kiểm tra xem danh sách có đang sửa đổi tin nhắn theo cách làm hỏng chữ ký DKIM của bạn không, và liệu chúng có triển khai ARC hay không.

Related RFCs