SpamAssassin

この用語をシェア

SpamAssassinとは

SpamAssassinは、Apache Software Foundationが管理するオープンソースのスパムフィルタリングソフトウェアです。もとはPerlで書かれたメール解析モジュールとして公開され、2004年にApacheのトップレベルプロジェクトへ昇格しました。以来20年以上にわたって開発が続く、メールサーバー向けスパム対策の事実上の標準ツールの一つです。

動作の中核はspamd（デーモン）とspamc（クライアント）という構成です。MTA（Postfix、Sendmail、Eximなど）から渡されたメールをspamcが受け取り、常駐しているspamdに転送、spamd側でルール評価・スコアリングを行った結果をヘッダーに付与して返す、という流れで動きます。デーモンを常駐させることでPerlの起動コストを毎回払わずに済み、都度プロセスを起動するより高速に処理できます。単体のフィルタというより、ヘッダー付与＋スコアリングのフレームワークと捉えると実運用がイメージしやすくなります。

現行の主要系統は4.0系で、Unicode正規化やホモグリフ（見た目が似た文字による偽装）対策、OpenSSL連携の強化などが盛り込まれています。3.4系からのアップグレードでは設定ファイルの互換性が概ね維持されているため、既存のlocal.cfやカスタムルールを大きく書き換えずに移行できる点も実務上のメリットです。

SpamAssassinの特徴

スコアリング方式

SpamAssassinは、1通のメールに対して数百〜数千のテスト（ルール）を実行し、それぞれのテストが持つスコア（重み）を合算する方式でスパム度を判定します。単一の理由でスパムと断定するのではなく、複数の弱い根拠を積み上げる「多層防御」的な考え方が特徴です。

• ヘッダー分析: Received経路の不整合、送信元IPの逆引き有無、Message-IDの形式異常などを検証
• 本文分析: キーワード、正規表現によるパターンマッチング、HTMLメールの構造チェック
• Bayesian Filter: 過去に学習したスパム／正常メールの単語出現頻度から統計的にスパム確率を算出する学習型フィルター
• RBLチェック: Spamhaus等のDNSブラックリストに送信元IPが登録されていないか照会
• SPF/DKIM検証: 送信ドメイン認証の合否をスコアに反映
• ネットワークテスト: Pyzor・Razor2・DCCなど、複数サーバーで同一メールの拡散状況を照合する分散型の指紋照合

合計スコアが閾値（デフォルトは5.0）を超えるとスパムと判定されます。閾値を下げるほど検知率は上がりますが誤検知（false positive）も増えるため、実運用ではまず5.0〜7.0程度で様子を見て、迷惑メールフォルダの中身を定期的にチェックしながら調整するのが定石です。

ルールの記述例

SpamAssassinのルールはテキストベースの独自DSLで記述します。以下は「特定の文字列を含み、かつRBLに載っている場合にスコアを加算する」独自ルールの例です。

# /etc/mail/spamassassin/local.cf に追記
# 件名に特定パターンを含む場合のカスタムルール
header   LOCAL_SUBJ_SUSPICIOUS  Subject =~ /\b(緊急|至急).{0,5}(振込|送金)\b/
score    LOCAL_SUBJ_SUSPICIOUS  3.0
describe LOCAL_SUBJ_SUSPICIOUS  Suspicious urgent-transfer wording in subject

# 特定送信元ドメインの信頼度を下げる例
header   LOCAL_FROM_FREEMAIL    From =~ /@(freemail-example)\.com/i
score    LOCAL_FROM_FREEMAIL    1.5

ルールはsa-compileでバイトコード化してからロードすることで、Perlの正規表現評価コストを下げ、処理速度を稼ぐ運用も可能です。大量のカスタムルールを追加している環境では、sa-compileの有効化がスループット改善に効きます。

主な機能

• ルールベース判定: カスタマイズ可能なルールセット（デフォルトルールは数千件規模）
• 自動学習: スパム／ハムの学習機能（sa-learn、bayes_auto_learn）
• 多言語対応: 日本語スパムを含む多言語のメールにも対応（文字コード変換・言語判定ルールあり）
• プラグイン拡張: Pyzor、Razor2、DCC、DKIM、SPF、TxRepなど公式・サードパーティのプラグインで機能追加が可能
• learning-only / autolearn: 明示的な学習コマンドに加え、高スコア・低スコアのメールを自動的に学習データへ取り込む仕組み

具体例・ユースケース

ケース1: 中小企業の自社Postfixサーバーでの一次フィルタ

自社でPostfixを運用している企業では、SMTP受信の直後にSpamAssassinを content_filter として噛ませ、スコアに応じてヘッダーに[SPAM]タグを付与し、Sieveルールで専用フォルダへ振り分ける構成がよく使われます。ユーザーごとに「迷惑メールフォルダを毎日1回だけ目視確認する」運用にすると、誤検知メールの見逃しを最小限に抑えつつ運用負荷も抑えられます。

ケース2: amavisd-newを介したウイルススキャンとの統合

Postfix環境では、SpamAssassin単体ではなくamavisd-newを中継させ、ClamAVによるウイルススキャンとSpamAssassinによるスパム判定を1つのパイプラインで同時に行う構成が広く採用されています。amavisd-newがcontent_filterとしてメールを受け取り、内部でSpamAssassinのライブラリ（Mail::SpamAssassin）を呼び出してスコアリングした後、Postfixへ返す流れです。ウイルス対策とスパム対策を別々のcontent_filterで多段にするより、1回のSMTPトランザクションで両方処理できるぶん構成がシンプルになります。

ケース3: ホスティング事業者・共用サーバーでのマルチテナント運用

cPanelやPleskなどのホスティング管理パネルには、SpamAssassinがスパムフィルタ機能として標準搭載されているケースが多く、ユーザー（ドメイン）ごとにBayesデータベースやスコア閾値を分けて運用できます。共用サーバーでは、あるユーザーの学習データが別ユーザーに影響しないよう、Bayesの保存先をユーザー単位のSQLiteやMySQLテーブルに分離するのが一般的です。

ケース4: ゲートウェイでの前段フィルタとDNSBL併用

MXレコードが指すゲートウェイサーバー段階でSpamAssassinを稼働させ、Spamhaus ZENなど複数のDNSBLと組み合わせることで、バックエンドの本番メールサーバーに届く前にスパムの大部分を弾く構成です。ゲートウェイで明らかなスパム（高スコア）は受信拒否（5xx応答）、グレーゾーンのスパムはタグ付けのみに留めて後段のIMAPクライアント側フィルタに委ねる、という段階的な運用がバランスが良いとされています。

メリット・デメリット

メリット

• オープンソースで無償: ライセンス費用なしで高機能なスパムフィルタを導入できる
• 20年以上の実績とドキュメントの豊富さ: 障害事例やチューニング情報がコミュニティ・書籍・ブログに蓄積されている
• ルールの柔軟性: 独自ルールを自由に追加でき、業種・組織固有のスパムパターンに対応しやすい
• 統合方法が多様: milter（spamass-milter）、procmail、Sieve、amavisd-new経由など複数の連携方式から選べる
• プラグインエコシステム: Pyzor/Razor2/DCCといった分散型フィルタとの連携で、単体ルールだけでは拾いにくい新種スパムにも対応

デメリット・注意点

• Perlベースゆえのリソース消費: spamdの子プロセスはメモリを比較的多く使うため、大量のメールを処理する環境ではメモリ・CPUがボトルネックになりやすい
• スループットの限界: 1通あたりの処理に数百ミリ秒〜数秒かかることがあり、rspamdのような非同期・イベント駆動型のフィルタと比べると大規模環境では見劣りする
• ルール更新を怠ると精度が落ちる: sa-updateを定期実行しないと新しいスパム傾向に追随できず、検知率が徐々に低下する
• 誤検知（false positive）調整の手間: 閾値やカスタムルールのチューニングを誤ると、正常な取引先メールがスパム扱いされ業務に支障が出ることがある
• 初期チューニングに学習コストが必要: Bayesの学習、DNSBLの選定、ルールの取捨選択など、最適化には一定の知識と試行錯誤が求められる

総じて、中小規模〜中堅規模のメールサーバーで「実績のある枯れた技術を使いたい」場合にはSpamAssassinが適しており、逆に大量送受信を捌く必要がある大規模環境では、後述するRspamdのような高速な選択肢も比較検討する価値があります。

Rspamdとの比較

SpamAssassinとよく比較されるのがRspamdです。両者は「複数のシグナルをスコアリングして合算する」という基本思想は共通していますが、実装言語とアーキテクチャが大きく異なります。SpamAssassinはPerlの同期処理モデル、Rspamdはイベント駆動（libev）の非同期処理モデルで、後者はRedisをバックエンドにした統計情報の共有が前提になっている点も設計上の違いです。

項目	SpamAssassin	Rspamd
実装言語	Perl	C
処理モデル	同期・プロセス常駐（spamd）	非同期イベント駆動
パフォーマンス	中程度	高速
メモリ使用量	大きい	小さい
統計情報の共有	SQLite/MySQL等（サーバー単位）	Redis前提（クラスタ共有しやすい）
管理UI	標準では無し（CLI中心）	WebUI標準搭載
学習コスト	低い（情報が豊富）	やや高い
導入実績	非常に多い	増加中

既存のSpamAssassin環境からRspamdへ移行する場合、SpamAssassinのルール（.cfファイル）の一部をそのまま読み込める互換モジュールがRspamd側に用意されていますが、100%互換ではないため、移行前に自環境で使っているカスタムルールが正しく動くかの検証は必須です。

自社メールサーバー運用への応用

Postfixとの連携設定

# main.cf - SpamAssassin連携
content_filter = spamassassin

# master.cf
spamassassin unix -     n       n       -       -       pipe
  user=spamd argv=/usr/bin/spamc -f -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}

content_filterではなく、milter方式（spamass-milter）を使う構成もあります。milter方式はSMTPセッションの早い段階でスコアを受け取れるため、明らかなスパムをDATAコマンドの受信自体を拒否する形で弾くことができ、帯域とディスクI/Oの節約になります。

# main.cf - milter方式の例（spamass-milter使用時）
smtpd_milters = unix:/var/spool/postfix/spamass/spamass.sock
non_smtpd_milters = $smtpd_milters
milter_default_action = accept

SpamAssassin設定例

# /etc/spamassassin/local.cf
required_score 5.0
rewrite_header Subject [SPAM]
report_safe 0
use_bayes 1
bayes_auto_learn 1
skip_rbl_checks 0

# spamdの並列度・タイムアウト（/etc/default/spamassassin 等）
# OPTIONS="--max-children 5 --timeout-child 30 -u spamd -H /var/lib/spamassassin"

spamdの--max-childrenはCPUコア数とメール流量に応じて調整します。子プロセス数を増やしすぎるとメモリ枯渇を招くため、まずは既定値から少しずつ増減させ、キューの滞留状況を見ながら調整するのが安全です。

SPF/DKIMのDNSレコードとの連携

SpamAssassinのSPF・DKIM検証プラグインは、あくまでDNS側に正しいレコードが公開されていることが前提です。自社ドメインで以下のようなTXTレコードを設定しておくことで、SpamAssassin側の送信元認証スコアが正しく機能します。

; SPFレコード例（自社の送信元IPを列挙）
example.com.        IN TXT  "v=spf1 ip4:203.0.113.10 include:_spf.google.com ~all"

; DKIM署名用の公開鍵レコード例（セレクタ: mail）
mail._domainkey.example.com. IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhki..."

; DMARCポリシー例
_dmarc.example.com.  IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

SPF/DKIMが未設定のドメインは、正規のメールであってもSpamAssassinのスコアがわずかに上振れしやすくなります。自社ドメインからの送信メールが誤ってスパム判定されるトラブルの多くは、この認証レコードの不備が原因であるため、SpamAssassin導入時にはSPF/DKIM/DMARCの設定状況を併せて確認することが実務上のポイントです。

Dovecot・Sieveとの連携

受信後の振り分けはDovecotのSieveプラグインと組み合わせるのが定番です。SpamAssassinが付与したX-Spam-Flagヘッダーを条件にフォルダ移動するSieveスクリプトの例は次の通りです。

require ["fileinto"];

if header :contains "X-Spam-Flag" "YES" {
    fileinto "Junk";
} else {
    keep;
}

学習機能の活用と運用の自動化

# スパムとして学習
sa-learn --spam /path/to/spam-mail

# ハム（正常メール）として学習
sa-learn --ham /path/to/ham-mail

# 学習状況確認
sa-learn --dump magic

# ルールセットの定期更新（cronで週2〜3回程度実行するのが一般的）
# /etc/cron.d/sa-update に以下のような設定を置くケースが多い
0 4 * * 1,4 root sa-update --nogpg && systemctl reload spamassassin

sa-updateはApacheが配布する公式ルールセットの更新に加え、サードパーティのルールチャンネル（例: SARE系の後継プロジェクトなど）を追加購読することも可能です。ただし出所不明なルールチャンネルを追加すると、意図しない過検知やパフォーマンス低下を招くことがあるため、信頼できる配布元かどうかを事前に確認してから利用するべきです。

関連ブログ記事

• Docker Mailserver完全ガイド
• メール認証技術SPF/DKIM/DMARC

まとめ

SpamAssassinは、20年以上の実績を持つスパムフィルタリングソフトウェアです。スコアリングという単純明快な仕組みでありながら、ヘッダー分析・Bayesian Filter・DNSBL照会・SPF/DKIM検証・分散型指紋照合まで幅広い手法を統合できる拡張性の高さが強みです。自社メールサーバーに導入する際は、Postfix/Dovecotとの連携設定に加えて、SPF/DKIM/DMARCのDNSレコード整備、sa-updateによるルールの定期更新、Bayesの継続的な学習という3点をセットで運用することで、実務に耐える精度を維持できます。大量のメールを高速に捌く必要がある大規模環境では、より高速なRspamdへの移行も検討する価値がありますが、中小規模の自社メールサーバーであれば、情報量の多さと枯れた安定性を理由にSpamAssassinを選ぶ判断は依然として合理的です。

よくある質問（FAQ）

この用語についてもっと詳しく

SpamAssassinに関するご質問や、メールサーバー構築のご相談など、お気軽にお問い合わせください。