web-dev-qa-db-ja.com

Gmailはメールを拒否します。 openspf.netがテストに失敗する

Gmailに問題があります。

これは、トロイの木馬に感染したPCの1つがIPアドレスから1日間スパムを送信した後に始まりました。

問題を修正しましたが、3つのブラックリストに入りました。それも修正しました。ただし、Gmailにメールを送信するたびに、メッセージは拒否されます。

そこで、Google Bulk Senderのガイドをもう一度確認し、SPFレコードにエラーを見つけて修正しました。グーグルはしばらくするとすべてが良くなるはずだと言っていますが、これは起こりません。 3週間が経過しましたが、まだGmailにメールを送信できません。

MXの設定は少し複雑ですが、多すぎません。ドメイン名はdelo-company.comで、独自のメール@ delo-company.comがあります(これは問題ありませんが、サブドメイン名に問題があります) corp.delo-company.com)。

Delo-company.comドメインには、サブドメインのいくつかのDNSレコードがあります。

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" 

(テスト目的でのみ〜allを設定しました。それ以前は-allでした)

これらのレコードは、82.209.198.147にある当社のExchange 2003サーバー用です。 LAN名はs2.corp.delo-company.comであるため、HELO/EHLOグリーティングもs2.corp.delo-company.comです。

EHLOチェックに合格するために、delo-company.comのDNSにもいくつかのレコードを作成しました。

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

私が理解しているように、SPF検証はこのように渡される必要があります:Outサーバーs2は受信者のMXに接続します(Rcp.MX):EHLO s2.corp.delo-company.com Rcp.MXはOKと言って、HELO /のSPFチェックを行いますEHLO。 s2.corp.delo-company.comに対してNSlookupを実行し、上記のDNSレコードを取得します。 TXTレコードは、s2.corp.delo-company.comはIP 82.209.198.147からのみである必要があることを示しているため、渡される必要があります。

次に、s2サーバーはRCPT FROM:Rcp.MX`サーバーもチェックします。値は同じであるため、正の値でもあるはずです。

RDNSチェックもあるかもしれませんが、HELOまたはRCPT FROMで何がチェックされるのかわかりません。

82.209.198.147のPTRレコードは次のとおりです。

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

私にはすべてが正常に見えますが、とにかくすべてのメールはGmailで拒否されます。

それで、私はMXtoolbox.comをチェックしました-それはすべてがうまくいくと私は渡しました http://www.kitterman.com/spf/validate.html Pythonチェック、私は25port.comの電子メールテストを行いました。

Return-Path: <[email protected]>
Received: from s2.corp.delo-company.com (82.209.198.147) by verifier.port25.com id ha45na11u9cs for <[email protected]>; Fri, 2 Mar 2012 13:03:21 -0500 (envelope-from <[email protected]>)
Authentication-Results: verifier.port25.com; spf=pass [email protected]
Authentication-Results: verifier.port25.com; domainkeys=neutral (message not signed) [email protected]
Authentication-Results: verifier.port25.com; dkim=neutral (message not signed)
Authentication-Results: verifier.port25.com; sender-id=pass [email protected]
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: <[email protected]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: test
Thread-Index: Acz4jS34oznvbyFQR4S5rXsNQFvTdg==
From: =?koi8-r?B?89XQ0tXOwMsg8MHXxcw=?= <[email protected]>
To: <[email protected]>

私も[email protected]で確認しましたが、どのSPFレコードを作成しても、常に失敗します。

<s2.corp.delo-company.com #5.7.1 smtp;550 5.7.1 <[email protected]>: Recipient address rejected: SPF Tests: Mail-From Result="softfail": Mail From="[email protected]" HELO name="s2.corp.delo-company.com" HELO Result="softfail" Remote IP="82.209.198.147">

Gmailフォームに2回記入しましたが、何も起こりません。

スパムは送信せず、クライアントへのメールのみを送信します。 corp.delo-company.comアドレスから大量のメール(新年の挨拶や販売促進など)を2〜3回行いましたが、それらはすべてGmailの一括送信者ガイド(つまり、SPF、オープンリレー、優先順位:一括および登録解除)に準拠していますタグ)。したがって、これは問題にはなりません。

私を助けてください。何が悪いのですか?

UPD:Unlocktheinbox.comテストも試しましたが、サーバーもこのテストに失敗しました。 ここ は結果です。 ここ はもう1つです。

また、Telnetを介してそのサーバーから手動でメールを送信しようとしましたが、すべて問題ありません。これが私がタイプしたものです:

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

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

そして、これは私が得るものです:

Delivered-To: [email protected]
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: <[email protected]>
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 [email protected] 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 [email protected] designates 82.209.198.147 as permitted sender) [email protected]
Date: Sat, 03 Mar 2012 09:17:00 -0800 (PST)
Message-Id: <[email protected]>
From: [email protected]
To: Pavel <[email protected]>
Subject: Test 28

This is telnet test
11
pablomedok

解決策を模索して50日経った後、Gmailは私たちのメールを受け入れ始めました。それらは通常の方法で受信トレイに渡されます(スパムとしてタグ付けされません)。

過去15日間、私は変更やその他の試みを行いませんでした。時間がかかるのは官僚や一部のアルゴリズムなのかはわかりませんが、私の考えでは、必要以上に10時間かかりました。弱いセキュリティに対する5日間のペナルティで十分です。

ちなみに、unlocktheinbox.comはテストに合格しましたが、openspf.orgテストはまだ失敗を報告しています。私の状況はテストには複雑すぎるようです。ドメイン名と一致するようにPTRとHELOの名前を修正します。

ただし、ISPにPTRを変更するように依頼してから1週間かかりましたが、それでも変わりません...もう1つの官僚的な問題です。

みんなの助けてくれてありがとう。

2
pablomedok

Microsoftには素晴らしいウィザードがあります。多分それはいくつかの変更を提案できますか?

http://www.Microsoft.com/mscorp/safety/content/technologies/senderid/wizard/

2
DerekC

sPFタイプのレコードなしで、TXTレコードのみを使用しているためと考えられますか?

rFC 4408を引用するには:

現在の慣行(TXTレコードを使用)は、
最適ではありませんが、DNSの数が多いため必要です
一般的に使用されるサーバーとリゾルバーの実装で処理できない
新しいRRタイプ。 2レコードタイプのスキームは、フォワードパスを提供します
この目的のために予約されているRRタイプを使用するより良いソリューションに。

SPF準拠のドメイン名には、両方のRRのSPFレコードが必要です(SHOULD)。
タイプ。準拠ドメイン名には、少なくとも1つのレコードが必要です
タイプ。ドメインに両方のタイプのレコードがある場合、それらは持っている必要があります
同一のコンテンツ。

1
Waleed Hamra