Có bản ghi SPF hợp lệ nhưng vẫn có thể giả mạo email của tôi

Tôi đã thiết lập bản ghi SPF cho tên miền của mình, nhưng tôi vẫn có thể giả mạo địa chỉ email cho tên miền của mình bằng các dịch vụ email giả như thế này: http://deadfake.com/Send.aspx

Các email đến hộp thư gmail của tôi tốt.

Email có lỗi SPF trong tiêu đề như thế này: spf=fail (google.com: domain of info@mydomain.com does not designate 23.249.225.236 as permitted sender)nhưng nó vẫn nhận được tốt, điều đó có nghĩa là bất kỳ ai cũng có thể giả mạo địa chỉ email của tôi ...

Bản ghi SPF của tôi là: v=spf1 mx a ptr include:_spf.google.com -all

CẬP NHẬT Trong trường hợp bất kỳ ai quan tâm, tôi đã xuất bản chính sách DMARC cùng với bản ghi SPF của mình và bây giờ Gmail đánh dấu các tin nhắn giả mạo chính xác (ảnh)

nhập mô tả hình ảnh ở đây

email spf

— jitbit
nguồn

Có, bất cứ ai cũng có thể giả mạo tên miền của bạn trong một email. Bản ghi SPF không ngăn chặn điều này trừ khi máy chủ nhận thực hiện từ chối cứng dựa trên lỗi SPF, điều mà có lẽ ít người làm được.

— joeqwerty

Vì bạn đã bao gồm _spf.google.com, chính sách của bạn có thể được đánh giá là ~allkhông -all. Bạn có thể chỉ cần một trong MX, Avà PTR.

— BillThor

@BillThor là tiêu chuẩn làm cho rõ ràng , mềm hoặc cứng từ một includebản ghi d bị bỏ qua khi đánh giá kết quả cuối cùng; hoặc như họ đã nói, " việc đánh giá một chỉ thị '-all' trong hồ sơ được tham chiếu không chấm dứt quá trình xử lý chung ".

— MadHatter

@MadHatter Có Tôi đã xem lại tài liệu sửa đổi với sự làm rõ đó. Nó không rõ ràng trong tài liệu trước đó và tôi tin rằng tôi đã gặp phải các triển khai dường như không tạo ra sự khác biệt. Không phải tất cả các triển khai xử lý các trường hợp cạnh như thế theo cách tiêu chuẩn. Tôi tin rằng đó có thể là lý do tại sao cần làm rõ.

— BillThor 13/03/2015

@BillThor bạn cũng có thể đúng! Như họ thừa nhận, includekhông phải là một tên hay cho chính sách, bởi vì mọi người có kinh nghiệm lập trình ngay lập tức đưa ra một loạt các giả định về cách thức hoạt động của nó - một số trong đó không đúng!

— MadHatter

Câu trả lời:

Thực tế là bạn quảng cáo một bản ghi SPF theo cách không bắt buộc ai khác phải tôn vinh nó. Tùy thuộc vào quản trị viên của bất kỳ máy chủ thư cụ thể nào mà email họ chọn chấp nhận. Tôi nghĩ họ thật ngu ngốc nếu họ không kiểm tra các bản ghi SPF và từ chối tương ứng, nhưng điều đó tùy thuộc vào họ . Tôi biết một số người thích DMARC, nhưng tôi nghĩ đó là một ý tưởng ghê tởm và tôi sẽ không cấu hình lại máy chủ email của mình để chấp nhận / từ chối dựa trên DMARC; chắc chắn một số người cảm thấy như vậy về SPF.

Những gì tôi nghĩ SPF không làm là cho phép bạn từ chối bất cứ trách nhiệm hơn nữa cho email mà tự xưng là từ tên miền của bạn, nhưng không phải vậy. Bất kỳ quản trị viên thư nào đến gặp bạn đều phàn nàn rằng tên miền của bạn đang gửi cho họ thư rác khi họ không muốn kiểm tra bản ghi SPF mà bạn quảng cáo sẽ nói với họ rằng email nên bị từ chối có thể được gửi đi bằng một con bọ chét trong tai họ.

— MadHatter
nguồn

SPF không thể ngăn chặn điều này. Nó chỉ đưa ra một dấu hiệu cho các máy chủ khác rằng thư bị giả mạo, nhưng hầu hết chỉ sử dụng một trong một số yếu tố để quyết định xem thư có bị chặn hay không.

— Sven
nguồn

OK, cảm ơn, đó là những gì tôi nghi ngờ ... Tôi thực sự ngạc nhiên khi Gmail không "tôn trọng" một lỗi spf như một lá cờ cảnh báo :(

— jitbit

@jitbit Gmail tôn trọng SPF, nhưng Hardfail SPF không có nghĩa là thư được gửi trực tiếp vào thư mục thư rác. Đây là một trong nhiều thông số để phát hiện thư rác.

— sebix

@sebix Cuối cùng tôi đã khiến Gmail coi đây là thư rác / độc hại, xem cập nhật trong câu hỏi

— jitbit 13/03/2015

Vâng, đó là bình thường. Bất cứ ai cũng có thể giả mạo bất kỳ địa chỉ email nào, nhưng SPF (Khung chính sách người gửi) cung cấp cho khách hàng và nhà cung cấp dịch vụ email khả năng xác định tốt hơn & gắn cờ là thư rác hoặc cuối cùng trả lại thư hoàn toàn nếu đó là một phần của quy trình của họ.

— nhà xác
nguồn