Tại sao email được gửi bình thường mặc dù có bản cứng SPF SPF?

Tôi đang cố gắng tìm hiểu tại sao email giả mạo lại được gửi đến các nhà cung cấp email lớn (gmail.com, triển vọng.com) ngay cả khi email được đánh dấu SPF hardfail. Email cũng được gửi đến Microsoft Exchange, nơi đang đưa ra một PermErrorbản ghi SPF tương tự.

Tôi đang gửi email bằng tên miền SOME_DOMAIN.com, định nghĩa bản ghi SPF bị hỏng. Email được truyền từ địa chỉ IP của chính tôi không được liệt kê rõ ràng trong bản ghi SPF của SOME_DOMAIN.com. Bản ghi SPF cho SOME_DOMAIN.com có ​​ba thuộc tính sau, hai thuộc tính đầu tiên là vi phạm SPF RFC-4408:

1. Do yêu cầu nhiều hơn 10 truy vấn DNS để giải quyết toàn bộ bản ghi SPF include:.
2. Lỗi cú pháp trong một trong các bản ghi SPF, python-spf đưa ra lỗi phân tích cú pháp.
3. Bản ghi SPF chứa cả quy tắc ~allvà -all, cả hai đều nói rằng tập hợp tất cả các địa chỉ nên softfailvàhardfail

Email được gửi đến một địa chỉ triển vọng mạo danh admin@SOME_DOMAIN.com sẽ chứa lỗi sau trong tiêu đề SMTP của email được gửi. Email này được gửi bình thường đến hộp thư đến của người dùng :

Received-SPF: PermError (: domain of SOME_DOMAIN.com used an invalid SPF mechanism)

Gmail cũng sẽ gửi email đến hộp thư đến của người dùng, nhưng sẽ gây ra lỗi SPF khác nhau:

spf=hardfail (google.com: domain of admin@SOME_DOMAIN.COM does not designate x.x.x.x as permitted sender) smtp.mail=admin@SOME_DOMAIN.COM

Chuyện gì đang xảy ra ở đây vậy? Tại sao email được gửi mặc dù có SPF hardfail? Có một bản ghi SPF bị hỏng có nghĩa là các máy chủ SMTP khác bỏ qua SPF hoàn toàn không? Hoặc có điều gì đó tôi đang thiếu ở đây ...

SPF được cấu hình quá tệ bởi rất nhiều trang web nhận MTA thường chỉ được coi hardfaillà tư vấn và chỉ đưa yếu tố này vào điểm số phát hiện spam của họ. Cuối cùng, tùy thuộc vào quản trị viên của MTA về việc các lỗi SPF sẽ được xử lý như thế nào.

Điều kiện lỗi SPF không cho biết bất cứ điều gì về chính sách mong muốn. Vì vậy, họ không cung cấp hướng dẫn về việc có chấp nhận tin nhắn hay không. Có thể là chính sách dự định là +all. Nó là bình thường để chấp nhận thư trong trường hợp này. Có vẻ như Google đang khoan dung với việc các miền này không tuân thủ tiêu chuẩn.

Ngay cả các từ chối chính sách SPF ( -all) cũng không đáng tin cậy khi xác thực địa chỉ người gửi. Có một số trường hợp từ chối thư như vậy sẽ không phù hợp, bao gồm:

• Thư được gửi bởi những người gửi thư có hợp đồng (Những người này được trả tiền để vi phạm chính sách.);
• Thư được gửi từ các mẫu web và hệ thống tự động khác như vậy;
• Thư được chuyển tiếp bằng danh sách gửi thư hoặc các cơ chế chuyển tiếp khác; và
• Chỉ cần cấu hình sai các bản ghi SPF (không phổ biến, nhưng không đủ hiếm).

Tôi chạy một máy chủ khá nhỏ, nơi tôi có thể trì hoãn khi gặp sự cố. Điều này cho phép tôi liệt kê những thất bại hợp pháp. Nếu người gửi thông báo thư không được gửi, họ có thể sửa cấu hình của họ. Trong một số trường hợp, tôi sẽ cố gắng liên hệ với người có liên quan postmaster, nhưng nhiều tên miền không có postmasterđịa chỉ.

Người dùng muốn thực thi chính sách mạnh hơn có thể sử dụng DMARC, đây chưa phải là tiêu chuẩn. Thư vẫn có khả năng được gửi, nhưng có thể bị cách ly hoặc từ chối theo quy định trong chính sách đó. Thư không thành công chính sách có thể được gửi đến thư mục thư rác, thay vì hộp thư đến thông thường.

SPF cứng dường như không đáng tin cậy để xác nhận danh tính của máy chủ gửi. Tôi đã thực hiện một số nghiên cứu trước đây và nhận thấy rằng ngay cả lỗi mềm trên tên Helo là một lý do hợp lý để thất bại hoặc trì hoãn các tin nhắn đến.

Nhiều máy chủ thư không có bản ghi SPF. Nếu máy chủ thư không có bản ghi SPF, tôi sẽ kiểm tra tên miền mẹ để xem bản ghi SPF. Điều này là không chuẩn, nhưng hiệu quả. Tôi khuyến khích các quản trị viên email đảm bảo có bản ghi SPF cho IP máy chủ như được liệt kê trong bản ghi PTR. Máy chủ của bạn cũng nên tự nhận dạng bằng tên được trả về bởi bản ghi PTR của nó. Xác minh bạn có bản ghi A tương ứng để xác minh DNS ngược.