あなたの XMail でセキュリティの高い良好なメッセージングサービスを行うために SPF ドメイン認証と DKIM ドメイン認証をセットアップしてください。
ただし、SPF 認証ステータスによる接続断を安易に実行してしまうと、かえって利用者の混乱を招く可能性があります。
たとえば「送ったメールが届かない」という強いクレームを受けるかもしれません。
また、接続元が Outlook や Thunderbird 等のメールクライアントであった場合、それらが接続断を「パスワードを再入力して送信する必要がある」と誤判断する場合があります。
これはクライアントユーザから見ると不可解な現象に見えるかもしれません。
このため、認証ステータスが "fail" の場合であっても当初は「そのまま行かせる」と対応するのが安全と思われます。
様子を見ながら徐々にセキュリティを高めてください。
インターネット電子メールは、差出人のメールアドレスを自由に指定することができますが、これがスパマーに利用され、差出人アドレスの詐称が広く行われるようになっています。
これに対抗する方法の一つとして SPF ドメイン認証があります。SPF ドメイン認証ではメールサーバへの接続元 IP アドレスが DNS(Domain Name System)に登録された IP アドレスに含まれているかをチェックします。
SPF ドメイン認証を実行すると、1通の電子メールの到着ごとに DNS サーバへの問い合わせが発生し、その応答を(場合によっては数秒間)待つことになります。
短時間に多くの電子メールが到着する環境では、これはメールサーバへの大きな負荷になる場合があります。
(*1) SPF 認証の対象にするドメインを選択します。"MAIL FROM: コマンドのドメイン名(推奨)" を推奨しますが、この場合の問題点と対応は以下の通りです。
- "MAIL FROM" が空白の場合 XMailCFG では "HELO" コマンドの値をドメイン名として認証します。
- 転送されてきたメッセージの場合、"MAIL FROM" が適切にセットされていない場合があり、認証に失敗することがあります。
ただし、送信元が XMail である場合、XMailCFG の [ユーザの管理]-[転送指定] で "転送時に元送信者アドレスを名乗る(推奨)" にすれば問題を軽減できます。
一方、"メッセージヘッダ From: のドメイン名 (SMTP DATA 後処理の場合に実行可能)" を選択した場合の XMailCFG の動作と問題点は以下のようになります。
- 送信者アドレス(メッセージヘッダFrom:)から得られるドメイン名を "MAIL FROM" から得られたデータと仮定して SPF 認証します。
- ヘッダに From: アドレスがない場合、"MAIL FROM" を送信者アドレスとみなして SPF 認証します。
(*2) XMail のローカルアカウントへの接続で SMTP 認証が利用された場合に SPF チェックを行わない場合にチェックをつけます。
SMTP 認証に成功するのは XMail ローカルアカウントが利用される場合なので、SPF 認証を行う必要がないと考えられます。
たとえば、大規模な LAN で XMail を利用する場合に SPF 認証処理によるサーバへの負荷を軽減させることができます。
(*3) ループバックアドレス(127.0.0.0/8)または LAN アドレスからのアクセスについても SPF 認証を行う場合にチェックをつけます。
LAN アドレスの IP 範囲は 10.0.0.0/8、172.16.0.0-172.31.255.255、192.168.0.0/16 です。
LAN 内で有効な SPF 認証を行うためには、参照先 DNS サーバに SPF レコードとしてすべての LAN 内アドレスを登録しておく必要があります。
LAN 内アカウント数が多い場合は XMail サーバの負荷が高くなる可能性があります。
(*4) 不正アクセスホストとの接続を切断する場合の応答コードとメッセージを以下のサンプルのように指定します。
451 Please try again later
550 Connection not accepted due to spam
554 Transaction failed
(何も指定しなかった場合、XMail 既定の応答コード(500番台)が不正アクセスホストに返ります)
451 の場合、同じホストから同じメッセージが再送されてくる可能性があります。500 番台の応答コードにすると致命的エラーとみなされて再送がない可能性があります。
ただし実際にどの対応になるかは接続元メールサーバまたはメールクライアントの既定値によります。
応答コードをどするかはあなたの組織の運営ポリシーによりますが、会社組織などでは 451 にするのが無難かもしれません。重要メールを受け取りそこねる可能性をいくらかでも低くできるからです。
なお、接続を切断した場合でも迷惑メールフォルダ機能を利用している場合は、応答コードにかかわらず、つまり接続元から見ると SMTP セッションに失敗してメッセージが届かなかったように見えているにもかかわらず、実際にはそれを受け取っていることに注意が必要です。
(*5) 迷惑メールフォルダ機能を実行すると、SPF ドメイン認証によって迷惑メールと判定された到着メッセージを任意のローカルフォルダまたは任意のローカルアカウントのメールボックスに保存できます。
- "迷惑メールの保存" オプションから保存先を選択してください。
- あて先アカウントがユーザアカウントかリストアカウントかにかかわらずメッセージを保存します。
- K4 で迷惑メールを管理する場合、以下のようにしてください。
- K4 はバージョン 0.91 以降をインストールする必要があります。
- 本ページで迷惑メールフォルダ機能の利用を実行します。
- [K4の管理]-[環境設定]-[基本設定] において "迷惑メールフォルダ機能の利用" を "許可する" にします。
- 迷惑メールフォルダに保存されたメッセージは 30 日経過後に警告なく削除されます。ただし、削除が実行されるのは (1) フォルダ内に新たなメッセージが追加保存されるとき、(2) ユーザが K4 にログインして [迷惑メール] メニューを開いたとき、(3) XMailCFG の [アンチ・スパム]-[迷惑メールフォルダの管理(スパムの管理)] メニューを開いたとき、となります。
設定情報は MailRoot/spam-spf-conf.tab に保存されます。
スパム処理の記録が本ページの [スパムログ] から閲覧できます。また、[アクセスログ] ページの [フィルタ処理のログ1 (XMailCFG)] または [フィルタ処理のログ3(XMailCFG-SPF認証)] からも参照できます。
[!!重要!!] 本機能は到着(インバウンド)メッセージに対する認証を行うものです。外部送信(アウトバウンド)メッセージが送信先の SPF 認証でどう取り扱われるかに影響するものではありません。
あなたの XMail からのアウトバウンドメッセージが送信先メールサーバで SPF 認証 OK になるようにするには、あなたの送信ドメインについて DNS(Domain Name System) に SPF レコードを登録する必要があります。
[参考例] DNS への SPF レコードの登録は以下のようにします。(送信ドメインが domain.com、IP アドレスが 100.200.30.** の場合)
domain.com. IN TXT "v=spf1 ip4:100.200.30.40 -all" (ドメインのメールサーバが1台の場合)
domain.com. IN TXT "v=spf1 ip4:100.200.30.40 ip4:100.200.30.41 -all" (ドメインのメールサーバが2台の場合)
domain.com. IN TXT "v=spf1 ip4:100.200.30.0/24 -all" (ドメインのメールサーバが 100.200.30.0/24 ネットワークに存在する場合)
K4、kml、XMailCFG のサポートサイトを開く。