Gmail từ chối email. Openspf.net thất bại trong các bài kiểm tra


11

Tôi đã gặp sự cố với Gmail.

Nó bắt đầu sau khi một trong những PC bị nhiễm trojan của chúng tôi gửi spam trong một ngày từ địa chỉ IP của chúng tôi.

Chúng tôi đã khắc phục sự cố, nhưng chúng tôi có 3 danh sách đen. Chúng tôi cũng đã sửa nó. Nhưng vẫn mỗi lần chúng tôi gửi email đến Gmail thì tin nhắn bị từ chối:

Vì vậy, tôi đã kiểm tra hướng dẫn Người gửi hàng loạt của Google một lần nữa và thấy lỗi trong bản ghi SPF của chúng tôi và đã sửa nó. Google nói rằng mọi thứ sẽ trở nên tốt đẹp sau một thời gian, nhưng điều này không xảy ra. Đã 3 tuần trôi qua nhưng chúng tôi vẫn không thể gửi email đến Gmail.

Thiết lập MX của chúng tôi hơi phức tạp, nhưng không quá nhiều: Chúng tôi có một tên miền delo-company.com, nó có mail riêng @ delo-company.com (cái này tốt, nhưng vấn đề là với tên miền phụ corp.delo-company.com).

Tên miền Delo-company.com có ​​một số bản ghi DNS cho tên miền phụ:

corp                     A     82.209.198.147
corp                     MX    20 corp.delo-company.com
corp.delo-company.com    TXT   "v=spf1 ip4:82.209.198.147 ~all" 

(Tôi đặt ~ tất cả chỉ cho mục đích thử nghiệm, đó là - tất cả trước đó)

Những hồ sơ này dành cho máy chủ Exchange 2003 của công ty chúng tôi tại 82.209.198.147. Tên LAN của nó là s2.corp.delo-company.com, vì vậy lời chào của HelO / EHLO cũng là s2.corp.delo-company.com.

Để vượt qua kiểm tra EHLO, chúng tôi cũng đã tạo một số bản ghi trong DNS của delo-company.com:

s2.corp                  A     82.209.198.147
s2.corp.delo-company.com TXT   "v=spf1 ip4:82.209.198.147 ~all" 

Theo tôi hiểu, việc xác minh SPF nên được thông qua theo cách này: Out server s2 kết nối với MX của người nhận (Rcp.MX): EHLO s2.corp.delo-company.com Rcp.MX nói Ok, và thực hiện kiểm tra SPF của HELO / EHLO. Nó hiện NSlookup cho s2.corp.delo-company.com và nhận các bản ghi DNS ở trên. Các bản ghi TXT nói rằng s2.corp.delo-company.com chỉ nên từ IP 82.209.198.147. Vì vậy, nó nên được thông qua.

Sau đó, máy chủ s2 của chúng tôi nói RCPT TỪ: Máy chủ Rcp.MX` cũng kiểm tra nó. Các giá trị là như nhau vì vậy chúng cũng phải tích cực.

Có thể cũng có kiểm tra rDNS, nhưng tôi không chắc chắn những gì được kiểm tra Helo hoặc RCPT TỪ.

Bản ghi PTR của chúng tôi cho 82.209.198.147 là:

147.198.209.82.in-addr.arpa. 86400 IN PTR s2.corp.delo-company.com.

Đối với tôi mọi thứ đều ổn, nhưng dù sao thì tất cả các email đều bị Gmail từ chối.

Vì vậy, tôi đã kiểm tra MXtoolbox.com - nó nói mọi thứ đều ổn, tôi đã vượt qua http://www.kitterman.com/spf/validate.html Kiểm tra Python, tôi đã kiểm tra email 25port.com. Cũng tốt thôi:

Return-Path: <supruniuk-p@corp.delo-company.com>
Received: from s2.corp.delo-company.com (82.209.198.147) by verifier.port25.com id ha45na11u9cs for <check-auth@verifier.port25.com>; Fri, 2 Mar 2012 13:03:21 -0500 (envelope-from <supruniuk-p@corp.delo-company.com>)
Authentication-Results: verifier.port25.com; spf=pass smtp.mailfrom=supruniuk-p@corp.delo-company.com
Authentication-Results: verifier.port25.com; domainkeys=neutral (message not signed) header.From=supruniuk-p@corp.delo-company.com
Authentication-Results: verifier.port25.com; dkim=neutral (message not signed)
Authentication-Results: verifier.port25.com; sender-id=pass header.From=supruniuk-p@corp.delo-company.com
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative;
    boundary="----_=_NextPart_001_01CCF89E.BE02A069"
Subject: test
Date: Fri, 2 Mar 2012 21:03:15 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Message-ID: <4C9EB1DB67831A428B2E14052F4A418707E1FF@s2.corp.delo-company.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: test
Thread-Index: Acz4jS34oznvbyFQR4S5rXsNQFvTdg==
From: =?koi8-r?B?89XQ0tXOwMsg8MHXxcw=?= <supruniuk-p@corp.delo-company.com>
To: <check-auth@verifier.port25.com>

Tôi cũng đã kiểm tra với spf-test@openspf.net, nhưng nó FAILs mọi lúc, bất kể bản ghi SPF nào tôi tạo:

<s2.corp.delo-company.com #5.7.1 smtp;550 5.7.1 <spf-test@openspf.net>: Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="supruniuk-p@corp.delo-company.com" HELO name="s2.corp.delo-company.com" HELO Result="softfail" Remote IP="82.209.198.147">

Tôi đã điền vào mẫu Gmail hai lần nhưng không có gì xảy ra.

Chúng tôi không gửi thư rác, chỉ gửi email cho khách hàng của chúng tôi. 2 hoặc 3 lần chúng tôi đã gửi email hàng loạt (như lời chúc mừng năm mới và khuyến mại bán hàng) từ các địa chỉ corp.delo-company.com, nhưng tất cả đều tuân thủ Hướng dẫn của người gửi hàng loạt Gmail (ý tôi là SPF, Rơle mở, Ưu tiên: Hàng loạt và Hủy đăng ký thẻ). Vì vậy, đây không phải là một vấn đề.

Làm ơn giúp tôi. Tôi đang làm gì sai?

CẬP NHẬT: Tôi cũng đã thử kiểm tra Unlocktheinbox.com và máy chủ cũng thất bại trong bài kiểm tra này. Đây là kết quả; đây là một trong những

Tôi cũng đã cố gắng gửi email từ máy chủ đó theo cách thủ công qua telnet và mọi thứ đều ổn. Đây là những gì tôi gõ:

220 mx.google.com ESMTP g15si4811326anb.170
HELO s2.corp.delo-company.com
250 mx.google.com at your service
MAIL FROM: <supruniuk-p@corp.delo-company.com>
250 2.1.0 OK g15si4811326anb.170
RCPT TO: <pablomedok@gmail.com>
250 2.1.5 OK g15si4811326anb.170
DATA
354  Go ahead g15si4811326anb.170
From: supruniuk-p@corp.delo-company.com
To: Pavel <pablomedok@gmail.com>
Subject: Test 28

This is telnet test
.
250 2.0.0 OK 1330795021 g15si4811326anb.170
QUIT
221 2.0.0 closing connection g15si4811326anb.170

Và đây là những gì tôi nhận được:

Delivered-To: pablomedok@gmail.com
Received: by 10.227.132.73 with SMTP id a9csp96864wbt;
        Sat, 3 Mar 2012 09:17:02 -0800 (PST)
Received: by 10.101.128.12 with SMTP id f12mr4837125ann.49.1330795021572;
        Sat, 03 Mar 2012 09:17:01 -0800 (PST)
Return-Path: <supruniuk-p@corp.delo-company.com>
Received: from s2.corp.delo-company.com (s2.corp.delo-company.com. [82.209.198.147])
        by mx.google.com with SMTP id g15si4811326anb.170.2012.03.03.09.15.59;
        Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Received-SPF: pass (google.com: domain of supruniuk-p@corp.delo-company.com designates 82.209.198.147 as permitted sender) client-ip=82.209.198.147;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of supruniuk-p@corp.delo-company.com designates 82.209.198.147 as permitted sender) smtp.mail=supruniuk-p@corp.delo-company.com
Date: Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Message-Id: <4f52520c.0f53640a.77bf.5626SMTPIN_ADDED@mx.google.com>
From: supruniuk-p@corp.delo-company.com
To: Pavel <pablomedok@gmail.com>
Subject: Test 28

This is telnet test

Bạn đã thử thay đổi bản ghi TXT từ ip4:82.209.198.147thành mx? Giống như bạn, tôi không thể thấy một lỗi, nhưng điều đó có thể đáng để thử.
James O'Gorman

Đã thử mx cho corp: <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <spf-test@openspf.net>: Địa chỉ người nhận bị từ chối: SPF Tests: Mail-From result = "permerror" : Mail From = "supruniuk-p@corp.delo-company.com" Helo name = "s2.corp.delo-company.com" Helo result = "softfail" Remote IP = "82.209.198.147">
pablomedok

Và mx cho s2.corp. <s2.corp.delo-company.com # 5.7.1 smtp; 550 5.7.1 <spf-test@openspf.net>: Địa chỉ người nhận bị từ chối: SPF Tests: Mail-From result = "softfail": Mail From = " supruniuk-p@corp.delo-company.com "Helo name =" s2.corp.delo-company.com "Helo result =" softfail "Remote IP =" 82.209.198.147 "> Cả hai đều là Softfail.
pablomedok

Bạn có DSN (Thông báo trạng thái gửi) cho tin nhắn bị trả lại không? Bạn có thể gửi nó? Bạn không nói liệu bạn có biết chắc chắn rằng SPF là lý do Gmail từ chối email của bạn hay không.
kls

Tôi có thể đưa nó cho bạn, nhưng nó bằng tiếng Nga: ы Làm thế nào để kiểm tra: kiểm tra 22 ngày hôm nay: 03 tháng 3 năm 2014, lúc đó là lúc đó là lúc đó là lúc đó là lúc đó là lúc đó là một thời gian khác nhau Ббббббббббб <s2.corp.delo-company.com # 5.5.0 smtp; 550-5.7.1 [82.209.198.147 3] Hệ thống của chúng tôi đã phát hiện một tỷ lệ bất thường> Thông báo bị ngắt sau dòng đầu tiên. Tôi đã nhìn thấy các bản ghi, sau đó là QUIT
pablomedok

Câu trả lời:



2

Sau 50 ngày cố gắng và tìm kiếm giải pháp, Gmail bắt đầu chấp nhận email của chúng tôi. Chúng chuyển đến hộp thư đến theo cách thông thường (chúng không được gắn thẻ là thư rác).

Tôi đã không thực hiện bất kỳ thay đổi hoặc bất kỳ cố gắng nào khác trong 15 ngày qua. Tôi không biết là nó quan liêu hay một số thuật toán mất quá nhiều thời gian, nhưng theo tôi thì nó mất nhiều thời gian hơn 10 lần so với bình thường. Hình phạt 5 ngày cho an ninh yếu của chúng tôi là đủ.

Nhân tiện, Unlocktheinbox.com hiện đã vượt qua bài kiểm tra, bài kiểm tra openspf.org vẫn báo cáo lỗi. Có vẻ như tình huống của tôi quá phức tạp cho bài kiểm tra. Tôi sẽ sửa tên PTR và Helo của mình để khớp với tên miền.

Tuy nhiên, phải mất một tuần sau khi chúng tôi yêu cầu ISP của chúng tôi thay đổi PTR và nó vẫn không thay đổi ... Một vấn đề quan liêu nữa.

Cảm ơn sự giúp đỡ của mọi người.


1

có thể là do bạn chỉ sử dụng các bản ghi TXT, không có bản ghi loại SPF?

để trích dẫn RFC 4408:

Người ta nhận thấy rằng thông lệ hiện tại (sử dụng bản ghi TXT) là
không tối ưu, nhưng điều đó là cần thiết bởi vì có một số
máy chủ DNS và trình triển khai trình phân giải được sử dụng phổ biến không thể xử lý
loại RR mới. Lược đồ hai bản ghi cung cấp một đường dẫn
tới giải pháp tốt hơn là sử dụng loại RR dành riêng cho mục đích này.

Một tên miền tuân thủ SPF NÊN có bản ghi SPF của cả hai
loại RR . Một tên miền tuân thủ PHẢI có một bản ghi ít nhất một
loại. Nếu một tên miền có bản ghi của cả hai loại, chúng PHẢI có
nội dung giống hệt nhau.


Bảng điều khiển lưu trữ của chúng tôi không hỗ trợ loại bản ghi SPF (chỉ a, aaaa, cname, ns, mx, srv, txt). Nhưng đó không phải là một vấn đề trước đây. Tôi chỉ không thể hiểu, tại sao một số dịch vụ vượt qua và một số dịch vụ khác không thành công. Và tại sao gửi tin nhắn thủ công qua Telnet lại thành công từ cùng một máy chủ? Có vẻ như có gì đó không đúng với cài đặt Exchange.
pablomedok

1
Đối với bất cứ ai đọc điều này bây giờ, hãy lưu ý rằng việc sử dụng SPFloại RR đã không được chấp nhận trong năm 2014. sử dụng TXT. Xem RFC 7208 để biết chi tiết.
mc0e
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.