Netskope SMTP プロキシは、SMTP 経由で送信される電子メールの DLP 違反をスキャンするサービスとして使用できます。 このソリューションでは、ユーザーが開始した電子メールは、MS O365 Exchange や Gmail などのクラウド電子メール サービスによって受信されます。 その後、電子メールは、SMTP ワークフローに統合されたNetskope SMTP プロキシを通過します。 Netskope SMTP プロキシは、電子メールの内容をリアルタイム保護ポリシーに照らして検証し、ポリシー設定に基づいて DLP 違反に対処します。 その後、電子メールは上流の MTA に渡され、そこで宛先電子メール サービスの DNS が検索され、電子メールが受信者のサーバーに送信されます。
SMTPプロキシは、単一のSMTPセッションで複数の電子メールメッセージを処理できます。これにより、電子メール サーバーの負荷が軽減され、大量のメッセージングにおける電子メールの待ち時間が短縮されます。
注記
中国のPoP（接続拠点）経由でアクセスされるアプリケーションには、SMTPプロキシは提供されていません。
SMTPプロキシは、SMTPエンベロープ内に有効かつ許可された送信者が指定されていることを保証します。これは、サービスが オープンプロキシとして扱われるのを防ぐために行われます。 「不在」の場合、送信者は空欄になります。これらはサービスを通じて中継できますが、2つのパラメータに関する要件があります。
- SNI
- SMTP設定でオプション属性を設定する必要があります。
GoogleやO-365などのサーバーはSNIを送信しますが、顧客はSMTP MSA設定でオプション属性を設定する必要があります。 この属性が電子メールの内容と一致すると、電子メールが許可されます。 また、送信者のない電子メールだけでなく、すべての電子メールがこの属性に一致する必要があります。
以下のフロー図は、ソリューションの概要を示しています。
前提条件
- Exchangeは正常に動作しており、MimecastやProofpointなどの上位MTAに接続されている必要があります。環境内にアップストリームMTAがない場合、 NetskopeからExchangeまたはGmailへのトラフィックをループバックできます。 詳細については、 「Netskope から Exchange へトラフィックを送信する」または「Netskope から Gmail へトラフィックを送信する」を参照してください。
- SMTP設定は 認証を必要としないアップストリームMTAである必要があります。
- Netskopeはポート25でTLS接続を必要とします。
- TLS 1.2と1.3のみがサポートされています。
制限事項
- あらゆるサイズの電子メールを MTA に転送できます。 DLPエンジンが処理するデフォルトのサイズは64MBで、タイムアウトは120秒です。
- SMTPプロキシには、RCPTコマンドの数に関する実装上の制限があります。これにより、残るRCPT TOコマンドに対して上流の電子メールサーバーに対して452ソフトエラーを返します。 これにより、上流デバイスは残りの受信者に対して再試行した後、電子メールを複数のコピーに分割することを強制します。 詳細については、 SMTP RFC を参照してください。
- Netskopeリアルタイム保護ポリシーを作成する際に、SMTPヘッダーを指定できます。Netskope SMTP プロキシは、電子メールの内容がポリシー定義に一致する場合に、このカスタム ヘッダーを電子メールに追加します。
Netskopeで指定されたカスタムヘッダーが の標準ヘッダーと同じ場合、 Netskope SMTPプロキシは標準ヘッダーの値をカスタムヘッダーの値に置き換えます。
例えば、 の標準ヘッダーが
X-ns-Exchange-CrossTenant-Network-Message-Id : "1234ABC"で、 Netskopeで指定されたカスタムヘッダーがX-NS-Exchange-CrossTenant-Network-Message-Id: "5678DEF"の場合、標準ヘッダーのメッセージ ID の値は、カスタムヘッダーのメッセージ ID の値に置き換えられます。 したがって、次のホップのMTAに送信されるヘッダーの最終値は「5678DEF」になります。注記
- Netskope 、 Netskope DLP ポリシーでカスタム ヘッダーを指定する場合、命名規則
X-NETSKOPE-<custom-header-name>を使用することをお勧めします。 - Netskope SMTP プロキシは、すべての電子メールにヘッダー
x-netskope-inspected: trueを追加します。 このヘッダーは、ポリシーアクションのカスタムヘッダーとして指定すべきではありません。 - ヘッダーはケースを区別せず、
x-netskope-inspectedはX-NETSKOPE-Inspectedと同じです。
- Netskope 、 Netskope DLP ポリシーでカスタム ヘッダーを指定する場合、命名規則
- ポリシーに複数のDLPプロファイルが含まれており、それぞれにカスタムSMTPヘッダーが設定され、複数のプロファイルが一致する場合、最初のプロファイルのアクションのみが適用されます。その結果、カスタムヘッダーは1つだけ追加されます。
- NetskopeのUIの「設定」>「セキュリティクラウドプラットフォーム」>「構成」では、このページのオプションはどれもSMTPプロキシには適用されません。これには「動的信頼ストア」も含まれます。
Microsoft Office 365およびGmailのテナント認証
テナント識別の際に、カスタムヘッダーを利用できます。これは、SNIが利用できない場合や、同じドメインが複数のテナントに構成されている場合に役立ちます。
Settings > Security Cloud Platform > SMTPに移動してUse Tenant Verification fields for Netskope Tenant Identificationを確認してください。
チェックボックスをオンにすると、UIに情報ボックスが表示されます。必要なキーと値のペアは Email Server Settingsに設定する必要があることを説明します。
Tenant Verification fieldが表示されます。
Microsoft O365:
Gmail:
