web-dev-qa-db-ja.com

FROMがsmtp.mailfromまたはリターンパスと一致しない場合にスパムをブロックするExchangeOffice365トランスポートルール

この種の質問はすでに回答済みだと思いますので、あらかじめお詫び申し上げますが、何も見つからないようです。 spf、dkim、dmarcがすべてセットアップされているので、送信スパムについて心配する必要はありませんが、ヘッダーを見ると明らかにスパムである受信スパムが送信されています。 \

認証が失敗し、smtp.mailfromとfromが異なり、toフィールドが受信者ではない場合にブロックする適切なトランスポートルールはありますか？また、件名とfromがエンコードされています。これが、基本的なスパムフィルタリングを乗り越えている方法かもしれません。

これは簡単なはずですが、何も見つかりません...

From: =?utf-8?Q?=C6=8Aropbox?= <[email protected]> 
Return Path: [email protected]
Message ID: <[email protected]>
To: <[email protected]>
Authentication-Results: spf=none (sender IP is 173.203.187.93) smtp.mailfrom=nutra-balance-products.com; mysitehere.com; dkim=none (message not signed) header.d=none;mysitehere.com; dmarc=none action=none header.from=onlineconnect.dpbox.com;
Subject: =?utf-8?Q?New_document_shared_-_=28investment-2018-en.pdf=29?= which decodes to New document shared - (investment-2018-en.pdf)
exchangespammicrosoft-office-365spam-filter
1
Bryan Willis

Return-Path（エンベロープ送信者）とFrom:の不一致は、必ずしもスパムを示しているわけではなく、メッセージをブロックするための明示的なルールとして使用しないでください。

たとえば、メーリングリストがサブスクライバーにメッセージを転送する状況が発生する可能性があります。メーリングリストは、元の送信者のSPFの動作を変更することはできず、（ RFC 4021、2.1.2 ）の作成者を指定するFrom:ヘッダーを変更しないでください。メッセージ。したがって、受信者側でSPFテストに合格するには、エンベロープ送信者を変更する必要があります。

Return-Path: <[email protected]>
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=198.51.100.30; 
    helo=mail.example.net; [email protected]; receiver=<UNKNOWN> 
To: <[email protected]>
From: "Original Sender" <[email protected]>

一方、Office 365のメールフロールールは、このような比較を行うようには設計されていません。たとえば、送信者をその場所（テナントの内部/外部）と比較したり、信頼できる外部サーバーのフィルタリングをバイパスしたりできます。これらは、ヒューリスティックが失敗する、より具体的な問題に対処するためのものです。

SPF/DKIM/DMARCが設定されている送信者からのみ正当なメールを受信すると思われる場合は、たとえば、 Authentication-Resultsとspf=noneを含むdkim=noneに基づいてSpam Confidence Level（SCL）を変更するルールを追加します。状況によっては、誤検知が発生する可能性があります。

2
Esa Jokinen