Bỏ qua tới phần tài liệu
Cơ sở kiến thức

Người gửi đã xác minh

Một dấu bên cạnh người gửi khi các bản ghi công bố của tên miền gửi khớp với nhau.

Chi tiết

  • Mọi thư bạn nhận đều mang một hàng Sender checks dưới mục Details, nêu rõ từng cơ chế trong ba cơ chế nói gì, có đạt hay không, và ai nói điều đó. Kết luận được tính lúc thư tới dựa trên những gì relay nhận thư báo cáo, nên nó là bản ghi về điều đã xảy ra chứ không phải một kiểm tra chạy khi bạn mở thư.
  • Kết luận được ĐỌC, không phải tính lại. Các máy chủ nhận thư cho bạn kiểm tra chữ ký so với thư đúng như lúc nó tới rồi ghi kết quả lên chính lần chuyển giao, bên cạnh thư chứ không phải bên trong nó; đó là điều mà con dấu báo cáo. Không có gì ở đây suy ra lại kết quả đó, bởi tự mình xác minh một chữ ký nghĩa là phải giữ nguyên byte gốc của mọi thư mãi mãi, mà một hộp thư ở đây chỉ giữ thread đã được phân tích. Tooltip nói rõ điều đó thay vì để con dấu ngụ ý điều ngược lại.
  • Một kết luận viết bên trong thư thì không bao giờ được tin. Authentication-Results là một header thông thường và bất kỳ người gửi nào cũng có thể tự viết một dòng nói mình đạt, nên một tuyên bố nằm trong thư được hiển thị như báo cáo của một người lạ chứ không phải như một phát hiện. Con dấu chỉ được vẽ trên những kết luận đi kèm lần chuyển giao, do chính các máy chủ đã nhận thư tính ra, phần duy nhất của một thư đang tới mà người gửi không thể viết.
  • DMARC và DKIM, không phải SPF. SPF trượt trên mọi thư được chuyển tiếp hợp lệ, vì bên chuyển tiếp không nằm trong bản ghi của tên miền gốc, nên đòi hỏi nó sẽ tước con dấu khỏi phần lớn thư đến hộp thư qua một danh sách hay một chuyển hướng. Một thư vượt qua cả ba sẽ nói rõ điều đó trên hàng Sender checks; một thư vượt DMARC mà không đủ cả bộ cũng nói rõ như vậy, và nêu tên đúng cơ chế đã hỏng thay vì mặc định cho là SPF. Một lần DKIM trượt đi kèm DMARC đạt thì hoàn toàn không bị coi là thất bại: DMARC đạt chỉ cần một cơ chế thẳng hàng, và một chữ ký bị chân trang của danh sách thư làm hỏng chính là lý do thông thường của cặp kết quả đó.
  • Kết luận lừa đảo có thứ hạng cao hơn. Một tài khoản bị chiếm quyền vẫn gửi thư được xác thực hoàn hảo, nên con dấu bị giữ lại trên bất kỳ thư nào bị đánh dấu là nguy hiểm: con dấu trả lời câu hỏi tên miền có đúng là nó tự nhận hay không, và nó không bao giờ được phép làm nhẹ đi lời cảnh báo trả lời câu hỏi thư này có an toàn hay không.
  • BIMI cố tình không nằm trong con dấu. Treo dấu này lên một logo đã công bố sẽ khiến một tên miền vượt qua mọi thứ lại chẳng hiện gì chỉ vì nó chưa bao giờ mua logo, và đó là sự thật về ngân sách tiếp thị chứ không phải về thư. Logo được vẽ ở đúng chỗ của nó, làm ảnh đại diện của người gửi, và nó bị giữ lại trên thư không vượt qua DMARC, bởi dấu hiệu thật của một thương hiệu đặt cạnh một địa chỉ giả mạo là điều thuyết phục nhất mà một trình đọc thư có thể làm giúp kẻ tấn công.
  • Không có dấu nghĩa là không có gì được chứng minh, chứ không phải có thứ gì đó đã trượt. Thư lưu trước khi các kiểm tra này tồn tại hoàn toàn không mang kết luận nào, và nói “not checked” thay vì mượn một kết quả đạt mà nó chưa từng giành được.