第 11章メールフィルター(milter)

管理するメールサーバーが SPAM メール送出の踏み台とならないための対策も必要ですが、一方で増加する SPAM メール受信への対策も講じなければなりません。SPAM の多くが送信元を偽装していることから受信したメールの送信元ドメインを認証するという方法が有効です。また、メールヘッダや本文に対してルールに従った検査を実施することでスパムを検知するといった方法もあります。

Turbolinux 11 Server では、これらの機能を実現するために以下のメールフィルター(Milter)を標準で用意し、Postfix での利用が可能になっています。Milter は、Postfix のアドオンプログラムとして独立した形で提供されています。初期状態ではいずれもオフ設定になっています。

表 11-1.

Milterデーモン概要
sid-milter/usr/sbin/sid-filterSPF(Classic SPF)や SenderID を使用した送信ドメイン認証
dk-milter/usr/sbin/dk-filterDomainKeys Miletr。電子署名を使用した送信ドメイン認証および送出するメールへの電子署名付与
dkim-milter/usr/sbin/dkim-filterDKIM Miletr。電子署名を使用した送信ドメイン認証および送出するメールへの電子署名付与
spamass-milter/usr/sbin/spamass-milterspamassassin の Milter。Postfix にフックしてメールメッセージを spamass-filter に渡す
spamassassin/usr/bin/spamdSpamAssasin が e-mail の SPAM を検知する際に使用するデーモン

11.1. 送信ドメイン認証

送信ドメイン認証の方式には大きく分けて IP アドレスベースのものと電子署名ベースのものとがあります。IP アドレスベースのドメイン認証は、メールのエンベロープにある SPF (Classic SPF)やメールヘッダの SenderID から送信元のドメインを取得し、送信元ドメインの DNS サーバーの TXT (SPF)レコードへと問いあわせを行うことで整合性を確認し認証を行います。メール送信側の DNS サーバーで SPF レコードが公開されていれば利用が可能なので手軽です。Turbolinux 11 Server では、IP アドレスベースの Milter として sid-milter を収録しています。

電子署名ベースのドメイン認証にもいくつかの方式があります。もっとも多く利用されてきたのは米 Yahoo! が提唱する DomainKeys です。他にも米 Cisco Systems が開発した IIM(Identified Internet Mail)や DomainKeys と IIM が統合された DKIM(DomainKeys Identified Mail)があります。Turbolinux 11 Server では DomainKeys Milter として dk-milter を、DKIM 用の Milter として dkim-milter を収録しています。電子署名ベースのドメイン認証の場合、送信元メールサーバーでは、秘密鍵を使用して電子署名を付与してからメールを送信します。受信側メールサーバーでは、送信元の DNS サーバーに問い合わせを行い公開鍵を入手して認証を行います。このように、送信元の DNS サーバーでは公開鍵を TXT レコードで公開し、メールサーバーには電子署名を付与するためのフィルタが必要になるため IP アドレスベースの方式と比較し、やや導入に手間がかかると言えます。

11.1.1. 送信ドメイン認証の結果と利用方法

ドメイン認証を実行した結果は“Authentication-Results”ヘッダに記録されます。書き込まれる内容は RFC で以下のように定義されています。

表 11-2. Authentication-Results

認証結果説明
Neutral公開なし
None“?”として公開されている
SoftFail“~”として公開されている
PermError記述誤りなどで認証に失敗
Pass認証成功
Fail認証失敗
TempError一時的にチェックが利用不可で認証失敗

現在のところ、ドメイン認証の普及率は決して高いとはいえず、すべてのドメインの DNS サーバーで SPF レコードや公開鍵を公開しているわけではありません。また公開をしたことによって送出するメールの受信を拒否されてしまっては意味がないという理由から、曖昧な設定“~all”(認証情報を公開しているが認証できないホストも含まれる)や“?all”(すべてのホストの認証情報を公開しない)と設定しているサーバーも多く存在しているのが現状です。ですから、受信側のメールサーバーは pass(認証成功)以外をすべて破棄するというポリシーで運用すべきではありません。まずは、fail や softfail も受信しメールボックスに格納するが、それらに対するエラーメールを返さない運用、さらに受信したメールのヘッダに結果を記述し受信側メールクライアントでの振り分けの参考とするといった運用から開始するのが適当です。今後、ドメイン認証のためのレコードを適切に公開するサーバーが増加し普及するに従って、SPAM 対策の効果は高くなると考えられます。

財団法人インターネット協会

http://www.iajapan.org/

WIDE プロジェクト Antispam Working Group

http://member.wide.ad.jp/wg/antispam/