web-dev-qa-db-ja.com

ハイブリッド展開で、Office 365へのすべての外部メールがSPFに失敗し、EOPによって迷惑メールとしてマークされる

つまり、EOP（Exchange Online Protection）が電子メールメッセージをジャンク（SCL5）としてスタンプし、SPFが失敗したため、正当な電子メールがジャンクフォルダーに到着しています。これは、クライアントのドメイン（contoso.com）に対するすべての外部ドメイン（たとえば、gmail.com/hp.com/Microsoft.com）で発生します。

背景情報：

私たちは、メールボックスをOffice 365（Exchange Online）に移行し始めています。これはハイブリッド展開/リッチ共存構成です。

  • オンプレミス= Exchange 2003（レガシー）＆2010（ハイブリッド展開用にインストール）
  • オフプレミス= Office 365（Exchange Online）
  • EOPはSPFチェック用に構成されています。
  • オンプレミスからExchange Onlineへのすべてのメールボックスの移行が完了していないため、MXレコードはオンプレミスを指しています。

問題は、外部ユーザーが組織のOffice 365メールボックスにメールを送信する場合（メールフロー：外部->メールゲートウェイ->オンプレミスメールサーバー-> EOP-> Office 365）、EOPがSPF検索とハード/ソフトを実行することですメールの送信元であるメールゲートウェイの外部IPアドレスを持つ失敗したメッセージ。

（オンプレミスのメールボックスではこの問題は発生しません。Office365に移行されたメールボックスのみが発生します。）

イラスト： Mail Flow from External to Office 365 with EOP

例1：MicrosoftからO365へ

Authentication-Results: spf=fail (sender IP is 23.1.4.9) 
smtp.mailfrom=Microsoft.com; contoso.mail.onmicrosoft.com;
dkim=none (message not signed) header.d=none;
Received-SPF: Fail (protection.Outlook.com: domain of Microsoft.com does not designate
23.1.4.9 as permitted sender) receiver=protection.Outlook.com; client-ip=23.1.4.9; 
helo=exchange2010.contoso.com; X-MS-Exchange-Organization-SCL: 5

例2：HPからO365へ

Authentication-Results: spf=none (sender IP is 23.1.4.9) 
smtp.mailfrom=hp.com; contoso.mail.onmicrosoft.com; dkim=none 
(message not signed) header.d=none; Received-SPF: None 
(protection.Outlook.com: hp.com does not designate permitted sender hosts) 
X-MS-Exchange-Organization-SCL: 5

例3：GmailからO365へ

Authentication-Results: spf=softfail (sender IP is 23.1.4.9) 
smtp.mailfrom=gmail.com; contoso.mail.onmicrosoft.com; 
dkim=fail (signature did not verify) header.d=gmail.com; 
Received-SPF: SoftFail (protection.Outlook.com: domain of transitioning 
gmail.com discourages use of 23.1.4.9 as permitted sender)  
X-MS-Exchange-Organization-SCL: 5

X-Forefront-Antispam-Reportのメッセージヘッダーについては、 http://Pastebin.com/sgjQETzM を参照してください。

注：23.1.4.9は、Exchange OnlineへのオンプレミスハイブリッドExchange 2010サーバーコネクタのパブリックIPアドレスです。

ハイブリッド展開の共存段階で、外部メールがEOPによって迷惑メールとしてマークされるのを防ぐにはどうすればよいですか？

[2015-12-12アップデート]

この問題は、設定とは関係がないため、Office 365サポート（エスカレーション/バックエンドチーム）によって修正されました。

次のことが提案されました。

  1. EOP許可リストでパブリックIPをホワイトリストに登録します（試してみました。役に立ちませんでした。）
  2. ドメインのSPFレコードを追加します： "v = spf1 ip4：XXX.XXX.XXX.XXX ip4：YYY.YYY.YYY.YYY include：spf.protection.Outlook.com -all"（この提案は有効だとは思わないでくださいEOPはgmail.comのSMTP IPアドレスに対してgmail.comをチェックしないでください。これは、gmail.comのSPFレコードで指定されていないためです。これは、SPFが機能する方法とは思われません。）
  3. TLSが有効になっていることを確認します（以下を参照）

重要な部分は3番目のポイントです。 「TLSが有効になっていない場合、ローカルExchangeからの受信メールは内部/信頼メールとしてマークされず、EOPはすべてのレコードをチェックします」とサポートは述べています。

サポートは、次の行でメールヘッダーからTLSの問題を特定しました。

  • X-MS-Exchange-Organization-AuthAs：匿名

これは、EOPが電子メールを受信したときにTLSが有効でなかったことを示しています。 EOPは受信メールを信頼メールとして扱いませんでした。正しいものは次のようになります：

  • X-MS-Exchange-Organization-AuthAs：内部

ただし、これは私たちの設定が原因ではありませんでした。サポート担当者は、Exchange 2010ハイブリッドサーバーからの詳細なSMTPログを確認することにより、設定が正しいことを確認するのに役立ちました。

ほぼ同時に、彼らのバックエンドチームは、何が原因か正確に知らせずに問題を修正しました（残念ながら）。

彼らがそれを修正した後、メッセージヘッダーに以下のようないくつかの重要な変更があることがわかりました。

Exchange 2003からOffice 365への内部発信メールの場合：

  • X-MS-Exchange-Organization-AuthAs：内部（「匿名」でした）

  • SCL = -1（SCL = 5でした）

  • Received-SPF：SoftFail（同じでした）

また、Office 365への外部メール（例：gmail.com）の場合：

  • X-MS-Exchange-Organization-AuthAs：匿名（同じでした）

  • SCL = 1（SCL = 5でした）

  • Received-SPF：SoftFail（同じでした）

SPFチェックは依然としてgmail.com（外部）のOffice 365へのソフトフェイルに失敗しましたが、サポート担当者はそれが問題なく、すべてのメールがジャンクフォルダーではなく受信トレイに送信されると述べました。

補足として、トラブルシューティング中に、バックエンドチームは一見軽微な構成の問題を1つ見つけました-IP許可リストで定義された受信コネクタ（つまり、Exchange 2010ハイブリッドサーバーのパブリックIP）からのIPがありました（別のOffice 365サポートによって提案されました）トラブルシューティング手順としての人物）。彼らは私たちにこれを行う必要はないはずであり、実際にそうすることはルーティングの問題を引き起こす可能性があることを私たちに知らせました。彼らは、最初のパスではメールがスパムとしてマークされていなかったので、ここにも問題の可能性があるとコメントしました。次に、IP許可リストからIPを削除しました。 （ただし、IP許可リストが設定される前はスパムの問題がありました。許可リストが原因であるとは考えていませんでした。）

結論として、「それはEOPメカニズムでなければならない」とサポート担当者は言った。したがって、すべてはそれらのメカニズムによって引き起こされるべきです。

興味のある方は、サポート担当者の1人とのトラブルシューティングスレッドをこちらでご覧いただけます。 https://community.office365.com/en-us/f/156/t/403396

exchangeexchange-2010spammicrosoft-office-365microsoft-forefront
11
wandersick

メールフローがハイブリッドサーバーからO365に直接送信されていますか？

ハイブリッドウィザードを実行すると、ローカルおよびO365でコネクタが作成され、フォレスト間のメールフローが内部メールとして処理されます。つまり、EOP /スパムチェックがバイパスされ、SPFメッセージが表示されることはありません。

Edgeデバイスがヘッダーを変更している場合、これが問題の原因である可能性があります。サーバーとO365の間では、メッセージヘッダーは変更されません。ハイブリッドウィザードで作成されたコネクタを上書きする可能性のある既存のコネクタがないことを確認してください。作成された既存のコネクタはいつでも削除でき、ウィザードを再実行してそれらを再作成できます。

Exchangeのトランスポートルールを確認し、O365に移動する前にメッセージが変更されていないことを確認します。無効になっている場合は再度テストして、問題がないことを確認します。

最後（またはおそらく最初）に、連携が正しく構成されていることを確認します。そうでない場合、メールが正しく処理されない可能性があります。ここで、ハイブリッドウィザードを再実行すると、同様に役立ちます。

2
Jesus Shelby

ここではエキスパートではありません。Exchangeで遊んだのは久しぶりですが、できる限りのことを答えたいと思います。

1秒の設計について議論しましょう。まず、すべてのトラフィックをEOPにルーティングしてから、社内のExchangeサーバーにルーティングしないのはなぜですか。そこにある優れた機能を失うと、単一の場所からスパムを制御することが確実に容易になります（ローカルのExchangeにもスパム対策フィルターがあると仮定します）。

さて、スパム問題に移りましょう：

  1. メールフローとコネクタ：すべての受信メールが同じ23.1から発信されているように見える場合、コネクタが正しく設定されていないと感じています。 4.9送信者のメールサーバーのIPアドレスではなくIPアドレス。送信者のIPとその送信者のIPのドメイン名を確認することが目的であるため、SPFチェックは必ず失敗します。コネクタの設定を確認するのに時間を費やすことは間違いありません。そのための良いリンクを以下に示します。 https://technet.Microsoft.com/en-us/library/ms.exch.eac.connectorselection（v = exchg.150）.aspx
  2. EOPスパムフィルターと接続フィルター：コネクターのIP設定が正しく行われている場合、おそらくEOPでスパム/接続フィルターを確認する時間、IP 23.1.4.9からの受信メールのチェックをバイパスするフィルターを作成しますが、すべての受信メールがスパムフィルターチェックリストをバイパスするため、前のポイントで述べた問題が発生し、コネクターを確認し、できれば、受信メールを最初にEOPにルーティングします。
1
Noor Khaldi