第39回　お久しぶりのSpamAssasin

過去2回ほどの記事では昨年暮れに起ったHDDトラブルについて紹介しました。先に触れたように、幸い今回は必要なファイルはほぼ全て回収できたので、元のシステムを復旧することも可能そうだったものの、さすがに7～8年前のPlamo-5.3くらいの環境に復旧しても使いづらいので、最新のPlamo-7.3環境でシステムを再構築することにしました。

普段使っている作業環境はテストを兼ねて新バージョンのPlamo Linuxを常にインストールしているものの、メールやWebといったサーバ系の環境は一度動き始めるとなかなか更新しづらいこともあり、本格的なリプレイスは久しぶりで、「⁠ああ、そう言えば……」的な感慨に耽（ふけ）りつつ、インストールや設定作業を進めました。

たいていのソフトウェアはPlamo Linuxのパッケージが用意されているので、設定ファイルを調整する程度で使えたものの、Apache SpamAssasinはPlamo用のパッケージを作って無かったこともあり、久しぶりに依存関係の底無し沼を経験することになりました（苦笑⁠）⁠。今回はこのSpam Assasin関連の経験を紹介しましょう。

Apache SpamAssasinのインストール

"Apache SpamAssasin"（以下SAと略）は、いわゆるアンチスパム（スパム対策用）ソフトウェアで、インターネット上に蔓延しているさまざまなスパム（迷惑メール）をブロックして、不要なメールに煩わされる手間を省いてくれます。

最近では、@niftyやbiglobeといったISPが提供するメールサービスだけでなく、Gmail等の無料メールサービスでもスパム対策やウィルスチェック機能が適用されているので、ほとんどの人はアンチスパム機能を意識することがないでしょう。

しかしながら、筆者のように独自ドメインで自前のメールサーバを運用している場合、日々流れてくる膨大な迷惑メールを自動ブロックするためのスパム対策は必須です。

もっとも、今回のシステム構築に際して久しぶりにスパム対策関連ソフトウェアを調べてみたところ、Gmail等の普及の結果か、この分野の活動は以前に比べてずいぶん下火になっているようで、解説記事等も新しいものはほとんど見つかりませんでした。一方、SAはそのような状況の元でも着実に開発が続いており、最新版は2021/04に公開された3.4.6で、スパムを判定するためのルールセットも頻繁に更新されています。

SAはPerlで書かれたスクリプトで、Perl用モジュールを提供しているCPANからも提供されているものの、必要な機能が細かく分割、モジュール化されており、それらを全て揃えるのはなかなか大変です。

$ perl -MCPAN -e shell
...
cpan shell -- CPAN exploration and modules installation (v2.22)
Enter 'h' for help.
cpan[1]> install Mail::SpamAssassin
Reading '/home/kojima/.cpan/Metadata'
  Database was generated on Thu, 21 Apr 2022 02:41:03 GMT
Running install for module 'Mail::SpamAssassin'
...
***************************************************************************
ERROR: the required HTML::Parser module is not installed,
minimum required version is 3.43.

  HTML is used for an ever-increasing amount of email so this dependency
  is unavoidable.  Run "perldoc -q html" for additional information.
.... 
ERROR: the required Net::DNS module is not installed,
minimum required version is 0.34.

  Used for all DNS-based tests (SBL, XBL, SpamCop, DSBL, etc.),
  perform MX checks, and is also used when manually reporting spam to
  SpamCop.
....
dependency check complete...

REQUIRED module missing: HTML::Parser
REQUIRED module missing: Net::DNS
REQUIRED module missing: NetAddr::IP
optional module missing: Digest::SHA1
optional module missing: Mail::SPF
...
No 'Makefile' created  SIDNEY/Mail-SpamAssassin-3.4.6.tar.gz
  /usr/bin/perl Makefile.PL -- NOT OK

上記リスト中、"REQUIRED"が必須の機能を提供するモジュール、"optional"は任意のモジュールです。もっとも、これらのモジュールをインストールするために、さらに別のモジュールが要求されたりするので、必要なモジュールは芋ヅル式に増えていきます。

行きつ戻りつしながら必要なモジュール類を作ってみたところ、最終的に67ものパッケージが必要となりました。

$ ls *tzst 
geoip_api_c-1.6.12-x86_64-B1.tzst                perl_IP_Country_DB_File-3.03-x86_64-B1.tzst
perl_Archive_Tar-2.40-x86_64-B1.tzst             perl_LWP_MediaTypes-6.04-x86_64-B1.tzst
perl_Archive_Zip-1.68-x86_64-B1.tzst             perl_MailTools-2.21-x86_64-B1.tzst
perl_BSD_Resource-1.2911-x86_64-B1.tzst          perl_Mail_AuthenticationResults-2.20210915-x86_64-B1.tzst
perl_B_COW-0.004-x86_64-B1.tzst                  perl_Mail_DKIM-1.20200907-x86_64-B1.tzst
....
perl_IO_String-1.08-x86_64-B1.tzst               re2c-2.2-x86_64-B1.tzst
perl_IO_Zlib-1.11-x86_64-B1.tzst
$ ls *tzst | wc -l
67

これらのパッケージをインストールすればSAは使えるようになるものの、実際にスパムフィルタとして使うためには、届いたメールをSAに送りこむ仕組みが必要です。

さてどうするか、としばし悩んだものの、まずは使いなれた方法がよかろうと、従来通りの「fetchmailで取り込んだメールをprocmailでSAに送りこむ」という最も簡単な方法を取ることにしました。

fetchmaiの設定ファイル（~/.fetchmailrc）とprocmail用の設定ファイル（~/.procmailrc）は認識できなくなったHDDから回収できているので、これらを新しい環境に持ち込めば必要な設定は完了です。

SpamAssasinの働き

SpamAssasin（SA）は、受け取ったメールをさまざまな観点からチェックして「スパムらしさ」を数値化し、その値が一定値（デフォルトは5.0）を越えたメールをスパムと判定します。

SAが評価した「スパムらしさ」は、メールのヘッダ部のX-Spam-Level:やX-Spam-Flag:行に記録され、どのような点でそのメールがスパムと見做（みな）されたかが判断できます。たとえば、手元に届いたとあるスパムでは、このような行がヘッダ部に追加されていました。

X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on pl74_1031.linet.jp
X-Spam-Flag: YES
X-Spam-Level: **************
X-Spam-Status: Yes, score=14.8 required=5.0 tests=FROM_SUSPICIOUS_NTLD,
    FROM_SUSPICIOUS_NTLD_FP,HTML_FONT_LOW_CONTRAST,HTML_MESSAGE,
    MIME_HTML_MOSTLY,MPART_ALT_DIFF,PDS_OTHER_BAD_TLD,RCVD_IN_SBL_CSS,
    RCVD_IN_VALIDITY_RPBL,SPF_HELO_NONE,SPF_NONE,T_KAM_HTML_FONT_INVALID,
    T_SCC_BODY_TEXT_LINE,URIBL_ABUSE_SURBL,URIBL_BLACK,XM_RECPTID
    autolearn=spam autolearn_force=no version=3.4.6

X-Spam-Status行に記録されているのが、SAがこのメールを「スパムらしい」と判断した観点で、"tests=..."以下に記録されているのがチェックに引っかかった項目になります。

スパムと判定されたメールには、より詳細なチェックレポートも付加されます。

Content analysis details:   (14.8 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                            [5.196.119.97 listed in zen.spamhaus.org]
 1.9 URIBL_ABUSE_SURBL      Contains an URL listed in the ABUSE SURBL
                            blocklist
                            [URIs: awesomewebsites.click]
 1.7 URIBL_BLACK            Contains an URL listed in the URIBL blacklist
                            [URIs: awesomewebsites.click]
 1.3 RCVD_IN_VALIDITY_RPBL  RBL: Relay in Validity RPBL,
                            https://senderscore.org/blocklistlookup/
                            [5.196.119.97 listed in bl.score.senderscore.com]
 ...
 2.0 PDS_OTHER_BAD_TLD      Untrustworthy TLDs
                            [URI: awesomewebsites.click (click)]
 ...
 3.0 XM_RECPTID             Has spammy message header

この表では、左から順に、pts欄が「スパムらしさ」の評価値、rule name欄がチェックした項目、description欄がその項目の説明、となっています。

ざっと見、最も評価値が高いのが3.6ptsのRCVD_IN_SBL_CSSで、zen.spamhaus.orgがチェックしているスパムによく使われるドメインを経由してきたことを示します。

1.9ptsのURIBL_ABUSE_SURBLは、メールの本文中にあるURLがABUSE SURBLが提供するURLブラックリストに載っていることを示します。

少し飛ばして、2.0ptsのPDS_OTHER_BAD_TLDは、メール本文中にある"awesomewebsites.click"というURLのTLD（Top Level Domain）である".click"が「信用できないTLD」であることを示します。

最後の3.0ptsが与えられた"M_RECPTIDは、説明では「スパムっぽいヘッダがある（Has spammy message header⁠）⁠」とされており、具体的にはスパムによく使われるメーラー（MUA）が生成するX-Mailer-ReceptID:などのヘッダをチェックしているようです。

SAでは、これら「スパムらしさ」を「ルールセット」でチェックしています。「⁠ルールセット」は/var/lib/spamassasin/以下に収められた"*.cf"ファイルに記述され、手元のバージョンでは60種類ほど用意されていました。

$ ls /var/lib/spamassassin/3.004006/updates_spamassassin_org
10_default_prefs.cf             20_uri_tests.cf           60_awl.cf
10_hasbase.cf                   20_vbounce.cf             60_bayes_stopwords.cf
...
20_porn.cf                      50_scores.cf              user_prefs.template
20_ratware.cf                   60_adsp_override_dkim.cf

先に見たRCVD_IN_SBL_CSSという項目は"20_dnsbl_tests.cf"というルールに記述されています。

$ cat -n 20_dnsbl_test.cf
  ...
  129  # CSS is the Spamhaus CSS Component of the SBL List: https://www.spamhaus.org/css/
  130  header RCVD_IN_SBL_CSS          eval:check_rbl_sub('zen', '127.0.0.3')
  131  describe RCVD_IN_SBL_CSS        Received via a relay in Spamhaus SBL-CSS
  132  tflags RCVD_IN_SBL_CSS          net
  133  reuse  RCVD_IN_SBL_CSS
  ...

このルールでは、メールが通過してきたドメイン（IPアドレス）が、SpamHausが提供する「スパムに利用されているアドレスリスト」に載っているかを調べます。問題のメールの場合、Received:行に記録されている"5.196.119.97"というアドレスが引っかかったようです。

SAの興味深い点は、各ルールの評価値（pts）が固定ではなく、実際に流通しているスパムを元に学習し、随時更新されるところです。ドキュメントによると、実際に流れてくるスパムメールを入力データとし、パーセプトロン形式のニューラルネットを用いてスパムの判定率がもっとも高くなるように各評価値を調整、その結果をルールセットと共に定期的に更新することで、スパムチェックをあの手この手ですり抜けようとするスパム業者に対抗し、フィルタリング精度を保ち続けているそうです。このような日々の努力が、20年以上に渡ってアンチスパム・ソフトウェアとして活用され続ける原動力なんだなぁ…… と感心しきりです。

話は変わりますが、ここ数ヵ月Gmailが不調で困っています。具体的には、届いたメールをGmailのアカウントにフォーワードする設定で、以前は特に問題無く送れていたメールが、最近ではしばしば"550-5.7.26"エラーとして受取を拒否されます。

Apr 19 09:49:44 localhost postfix/smtp[4079]: E806A1E7804D: to=<kojima3216@gmail.com>,
  relay=gmail-smtp-in.l.google.com[64.233.188.27]:25, delay=1.4, delays=0.17/0.01/0.49/0.74,
  dsn=5.7.26, status=bounced (host gmail-smtp-in.l.google.com[64.233.188.27] said: 550-5.7.26
  This message does not have authentication information or fails to 550-5.7.26 pass
  authentication checks. To best protect our users from spam, the 550-5.7.26 message has
  been blocked. Please visit 550-5.7.26  https://support.google.com/mail/answer/81126#authentication
  for more 550 5.7.26 information. e15-20020a17090a7c4f00b001cd51f48295si674368pjl.174 - gsmtp
  (in reply to end of DATA command))

同様の現象は筆者以外にも起きているようで、Plamo Linuxのメーリングリストに何か投稿があるたび、そのメールをGmailのアカウントへフォーワードできなかった旨を報せるエラーメールが大量に発生しています。

なりすましメールを防ぐためのSPF（Sender Policy Framework）やDKIM（DomainKeys Identified Mail）を設定すればいいのでは、といわれているものの、見る限り、同じドメイン、同じメールアドレスから送信されたメールの半数が転送時にハジかれる上、上記エラーメッセージの最後に"in reply to end of DATA command"とあるように、ヘッダのSPFやDKIMだけではなく、メール本文の内容もチェックした上で受信拒否（bounced）されている気配です。

ロシアのウクライナ侵攻に便乗したサイバー攻撃が急増した結果、Gmailがチェックを強化した、という話もあるようですが、実際のところは闇の中で、イライラが募（つの）るばかりです。

SpamAssasinが、OSSとしてスパム業者に対してすら自らの判定ルールや重み付けを公開しながら戦い続けているのと比べると、Google/Gmailはかっての輝きを失なってしまったなぁ…… と感じてしまいます。