SPF は送信者をなりすますスパムメールやフィッシングメール (なりすましメール、スプーフィングメール) を防止する送信ドメイン認証のひとつです。SPF では送信元 (接続元) のIPアドレスが送信者 (エンベロープの送信者) または HELO/EHLO に指定されたドメインの SPF レコードに含まれているかをチェックします。
InterScan MSSでは、Patch 1 Hotfix 1419からpostfix向けのSPF検証機能の提供を開始いたしました。
SPF (Sender Policy Framework) の仕組み
SPF における送信ドメイン認証の仕組みを簡単に説明します。
検証するドメイン
SPF ではメッセージヘッダ (From ヘッダ) ではなくエンベロープの送信者 (SMTP トランザクションにおける MAIL FROM のコマンドに指定されたメールアドレス) のドメインを検証します。
また、配信不能通知 (バウンスメール) など、一部のメッセージは MAIL FROM に null ("<>") を指定する決まりであるため、その場合、送信者のドメインとして SMTP クライアント (配送元のメールサーバやメールクライアント) が HELO/EHLO コマンドに指定するホスト名が検証対象となります。
SPF レコード
ドメインが SPF に対応している場合、次のような SPF レコードが DNS の TXT レコードで登録されています。
v=spf1 +mx a:smtp.example.com ip4:192.168.1.100 ip4:192.168.2.100 -all
SPF レコードは左から右に順に評価され、修飾子 ("+" や "-" など) によって評価が決定します。
+: Pass (修飾子が指定されていない場合は + とみなされます)
-: Fail
~: Softfail
?: Neutral
したがって、前述の SPF レコードは以下の意味になります。
+mx | MX レコードに指定されたホスト (そのホストに対する A レコードのIPアドレス) は評価を Pass とします |
a:smtp.example.com | smtp.example.com の A レコードに登録されたIPアドレスは評価を Pass とします |
ip4:192.168.1.100 | IPv4 のIPアドレス 192.168.1.100 は評価を Pass とします |
ip4:192.168.2.100 | IPv4 のIPアドレス 192.168.2.100 は評価を Pass とします |
-all | 上記に合致しない接続元IPアドレスは評価を Fail とします |
例えば gmail.com の場合、2021年9月現在、SPF レコードは次のようになっています。
gmail.com. 300 IN TXT "v=spf1 redirect=_spf.google.com"
"redirect" は _spf.google.com の SPF レコードにリダイレクトすることを意味しています。_spf.google.com の SPF レコードは次のようになっています。
_spf.google.com. 300 IN TXT "v=spf1 include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com ~all"
"include" は _netblocks.google.com や _netblocks2.google.com, _netblocks3.google.com の SPF レコードを再帰的に評価することを意味しています。例えば _netblocks.google.com の SPF レコードには多くのIPアドレスの範囲が指定されています。
_netblocks.google.com. 3600 IN TXT "v=spf1 ip4:35.190.247.0/24 ip4:64.233.160.0/19 ip4:66.102.0.0/20 ip4:66.249.80.0/20 ip4:72.14.192.0/18 ip4:74.125.0.0/16 ip4:108.177.8.0/21 ip4:173.194.0.0/16 ip4:209.85.128.0/17 ip4:216.58.192.0/19 ip4:216.239.32.0/19 ~all"
したがって、gmail.com の SPF レコードは _spf.google.com にインクルードされた _netblocks.google.com, _netblocks2.google.com, _netblocks3.google.com の各 SPF レコード の評価に依存します。
SPF の評価
SPF の検証では次のいずれかの評価が返されます。
評価 | 説明 |
---|---|
None | ドメインに SPF レコードがない場合など。 |
Neutral | 接続元IPアドレスが "?" と判定された場合。許可/拒否を示さない場合に使用。 |
Pass | 接続元IPアドレスが "+" と判定された場合。明示的に許可する場合に使用。 |
Fail | 接続元IPアドレスが "-" と判定された場合。明示的に拒否する場合に使用。 |
Softfail | 接続元IPアドレスが "~" と判定された場合。弱い拒否を示す場合に使用。 |
Temperror | DNS サーバに接続できないなど、一時的なエラーで評価できなかった場合 |
Permerror | ドメインの SPF レコードの記述に問題があり、評価できなかった場合 |
設定方法
-
InterScan MSSは直接インターネットからメッセージを受信する場所 (メールゲートウェイ) に配置されている必要があります。InterScan MSSが内部メールサーバ間に配置されている場合には正しく検証することはできません。
-
クラウドプレフィルタを利用している場合、「white_ip」のパラメータにクラウドプレフィルタのIPアドレスをすべて記述する必要があります。
-
内部ドメインに対して判定する場合、そのドメインの DNS に適切な SPF レコードが用意されている必要があります。DNS の管理者に依頼して SPF レコードを用意してください。
-
SPF ではバウンスメール のように MAIL FROM に null ("<>") が指定されている場合、HELO/EHLO コマンドに指定するホスト名が検証対象となります。「InterScan MSSが送信する当該メールを、他のメールサーバがSPF検証する」ケースを想定する場合、InterScan MSSの各ホスト名に対しても SPF レコードを用意する必要があります。
InterScan MSSがメールを送信する際に使用するHELO/EHLOのホスト名を変更されたい場合は、ご利用のMTAソフト(postfix, sendmail)の該当する設定を変更してください。詳細は合わせてこちらをご参照ください。
InterScan MSS において SPF を検証する場合、まずこちらから SPF 設定ガイドをダウンロードし、当該ガイドの「SPFを有効にするには」に記載の設定を行います。
その後、SPFの設定ファイルconfig.iniに対して設定を行います。
一般的な設定例は次のとおりです。
-
viエディタでSPFの設定ファイル config.ini を開き、以下の設定を変更します。
例えば内部から送信されるメッセージに対して検証しないようにするには、[globals] セクションにあるパラメータ white_ip に以下のように内部ネットワークのIPアドレスを追加します。
/opt/trend/imss/SPFPolicyd/config.ini:[globals] ... #white_ip=127.0.0.1 white_ip=127.0.0.1,192.168.0.1/24 ...
また、SPF の評価に対する処理は初期設定では以下となっています。
/opt/trend/imss/SPFPolicyd/config.ini:[globals] ... none=bypass neutral=bypass pass=bypass fail=block softfail=tempblock temperror=bypass permerror=bypass
bypass, tempblock, block の各処理の意味は以下となります。
処理 説明 bypass 何もしません tempblock 一時的にメール受信を拒否します block 恒久的にメール受信を拒否します Received-SPF ヘッダを追加するだけでメッセージをブロックしないのであれば、次のように処理を bypass にすべて設定してください。
/opt/trend/imss/SPFPolicyd/config.ini:[globals] ... none=bypass neutral=bypass pass=bypass #fail=block fail=bypass #softfail=tempblock softfail=bypass temperror=bypass ...
-
以下のコマンドを実行して Postfix のサービスを再起動します。
# service postfix restart または # systemctl restart postfix.service
ブロックした場合の動作
処理方法が block と tempblock でブロックの動作は異なります。
処理が block の場合
接続元 (送信元) のメールサーバなど、InterScan MSS に接続する SMTP クライアントに対して 550 の応答を返し、恒久的にメールの受信を拒否します。その場合、メールログ (/var/log/maillog) には次のようなログが出力されます。
Sep 8 12:18:37 imss91 SPFPolicyd[13702]: [SPFPolicyd.py:208][Normal] Client IP: 172.16.10.100; Sender: ; Helo Name: mail.example.com; Action: global, block. Sep 8 12:18:37 imss91 postfix/smtpd[13697]: NOQUEUE: reject: RCPT from unknown[172.16.10.100]: 550 5.7.1 : Sender address rejected: Service unavailable; SPF check failed and transaction closed due to the organization's policy.; from= proto=ESMTP helo=
処理が tempblock の場合
InterScan MSS に接続する SMTP クライアントに対して 451 の応答を返し、一時的にメールの受信を拒否します。その場合、メールログ (/var/log/maillog) には次のようなログが出力されます。
Sep 8 12:42:50 imss91 SPFPolicyd[23032]: [SPFPolicyd.py:208][Normal] Client IP: 172.16.10.100; Sender: john@example.com; Helo Name: mail.example.com; Action: global, tempblock. Sep 8 12:42:50 imss91 postfix/smtpd[23028]: NOQUEUE: reject: RCPT from unknown[172.16.10.100]: 451 4.7.1 : Sender address rejected: Service temporarily unavailable; SPF check failed and transaction closed due to the organization's policy.; from= proto=ESMTP helo=
・上記ログサンプルではIPアドレスがプライベートIPアドレスになっていますが、通常グローバルIPアドレスが表示されます。
・posftixの設定ファイルmain.cfの設定smtpd_delay_rejectはデフォルトで"yes"となっております。そのため、デフォルトではRCPTコマンド受信時にpostfixは受信拒否応答を返すことになります。
Received-SPF ヘッダの追加
処理方法に bypass を選択した場合、SPF の評価に応じて以下のような Received-SPF ヘッダが追加されます。
評価が None の場合
Received-SPF: None (imss91.trendmicro.com: domain of john@example.com does not designate permitted sender hosts) identity=MAILFROM; client-ip=172.16.10.100; envelope-from=john@example.com; helo=mail.example.com)
評価が Neutral の場合
Received-SPF: Neutral (imss91.trendmicro.com: 172.16.10.100 is neither permitted nor denied by domain of john@example.com) identity=MAILFROM; client-ip=172.16.10.100; envelope-from=john@example.com; helo=mail.example.com)
評価が Pass の場合
Received-SPF: Pass (imss91.trendmicro.com: domain of john@example.com designates 172.16.10.100 as permitted sender) identity=MAILFROM; client-ip=172.16.10.100; envelope-from=john@example.com; helo=mail.example.com)
評価が Fail の場合
Received-SPF: Fail (imss91.trendmicro.com: domain of john@example.com does not designates 172.16.10.100 as permitted sender) identity=MAILFROM; client-ip=172.16.10.100; envelope-from=john@example.com; helo=mail.example.com)
評価が Softfail の場合
Received-SPF: SoftFail (imss91.trendmicro.com: domain of transitioning john@example.com discourages use of 172.16.10.100 as permitted sender) identity=MAILFROM; client-ip=172.16.10.100; envelope-from=john@example.com; helo=mail.example.com)
評価が Temperror の場合 (DNS サーバに接続できなかった場合)
Received-SPF: TempError (imss91.trendmicro.com: error in processing during lookup of john@example.com: SPF Temporary Error: DNS [Errno 111] Connection refused) identity=MAILFROM; client-ip=172.16.10.100; envelope-from=john@example.com; helo=mail.example.com)
評価が Permerror の場合
Received-SPF: PermError (imss91.trendmicro.com: domain of john@example.com uses mechanism not recognized by this client) identity=MAILFROM; client-ip=172.16.10.100; envelope-from=john@example.com; helo=mail.example.com)
上記ログサンプルではIPアドレスがプライベートIPアドレスになっていますが、通常グローバルIPアドレスが表示されます。
ポリシールールで検出する
SPF の検証に失敗した場合に SMTP 接続を拒否するのではなくメッセージを隔離したい場合など、ポリシールールによる検索で検出してメッセージを処理する場合には「設定方法」の手順 3 にしたがって各評価の処理を "bypass" に設定した上で Received-SPF ヘッダのキーワードを検索条件に設定したポリシールールを任意に作成してください。
キーワードリスト作成例
管理コンソールの ポリシー > ポリシーオブジェクト > キーワードリスト を開き、[追加] ボタンから任意のキーワードリストを追加します。
前述の Received-SPF ヘッダ例であれば、Fail の判定のメッセージのみを検出する場合、次のキーワード (正規表現) をキーワードリストに登録します。
^Fail \(imss91\.trendmicro\.com
あるいは、Fail または Softfail と判定されたメッセージを検出するのであれば以下のキーワード (正規表現) を登録します。
^(Fail|SoftFail) \(imss91\.trendmicro\.com
通常キーワードは ^Fail や ^(Fail|SoftFail) だけでもいいのですが、他の MTA が追加した Received-SPF を検出する場合があるため、上記例では厳密に InterScan MSS のホスト名 までキーワードに含めています。
ポリシールール作成例
次のような新しいポリシールールを作成します。
「受信メッセージ」を選択します。宛先をクリックして ポリシー > 内部アドレス に登録されたドメインを登録します。
「ヘッダのキーワード」を選択します。「ヘッダのキーワード」をクリックし、「その他」を選択して Received-SPF と入力します。最後に事前に作成したキーワードリストを選択します。
例えばメッセージを隔離するのであれば「次の場所に隔離」、メッセージを削除するのであれば「メッセージ全体を削除」を選択します。
メッセージを隔離したり、削除する場合、設定当初は「メッセージをインターセプトしない」を設定し、検出状況をログで確認した上で最終的に設定することを推奨します。なお、ポリシールールによって検出されたかどうかは ログ > ログクエリ 画面で検索して確認できます。