1  SMTPレベルでのspam送信機能改善

数年前から MTA レベルの spam フィルタ技術として tarpitting + greylist 等を適用しているが、最近どうも効きが悪い感じがしたので、すり抜けてくる spam について少し調査をしてみた。結論としては spam 送信ソフトの実装レベルがかなり上がってきた事が伺える。

SMTP的な挙動が正常なMTAと区別が付かないspammerの増加

Greylist (わざと再送要求する) や Tarpit (応答コード送信を遅延させる) といった手法に普通の MTA と同じようにきちんと対応してくる spammer が増えてきている。元々 spam 送信者のソフトウェアが真面目に実装されていない事を利用した手法なので、真面目に実装した方が spam 送信率が高くなると認識された時点で対応されるのはある意味当然ではあるのだが、思ったより早く対応が進んでいる。
その他でも、HELO/EHLO できちんと FQDN を送信してきたり、セカンダリMXを参照して再送をかけてきたりと、全般的にSMTP的な振る舞いは正しいMTAと区別できないレベルのものが確実に増えてきている。特に英語spamに顕著。

ISPの真っ当なメールサーバを中継してくるspammerの増加

正当なISPのメールサーバから正当なFromで送りつけてくる spammer が最近は多少目立つようになってきた。ほぼ同じ内容のspamが複数の送信者・ISP経由から来ているのを見るに、恐らくはウィルス感染PCのbotnetから広く浅く送ってきているのだろう。これをやられるともうSMTPレベルではフィルタのしようがなく、本文の文章解析に頼るしかない。

2  From / To / Subject / Body の工夫

SMTPレベル以外でも、From / To や Subject, 本文自体にも色々と工夫が見られる。

From が自分自身 (To と同一) であったりランダムであったりする

SpamAssassin では blacklist_from と言う From 固定フィルタがあるが、これが使えなくなる。From が自分自身と言うケースに付いては SPF のような送信サーバ認証を使う手はあり、SpamAssassin 等でも whitelist_from_spf と言った SPF 認証された From のみを Whitelist として扱う設定がある。
個人的な問題は私の主メールアドレスのドメインを登録している NSI が未だに TXT レコードの編集に対応していないという所だが、SPF 対応サーバ自体は去年のドコモの PSF フィルタ開始から増加している。

Subject や本文にスペルミスを入れてくる

英語spamでの話になるが、固定文字列フィルタをすり抜けるためにわざとキーワードをスペルミスしてくる。よくあるのは Viagra を Viagara や Viarga と言ったようなもの。

今のところはまだこうしたインテリジェントなspammerは大多数ではないため、既存の手法もそれなりの割合では効いているが、出来のいいツールが出回るようになると現行の手法では対処が難しくなるだろう。まめにメンテナンスされた DNSRBLs 、ドメイン認証、フロー制御、あとはコンテンツレベルでのより賢いフィルタリング等の重要性が増していくだろうが、より CPU リソースを消費する方向に進んでいると言うのはかなり憂鬱な話ではある。

どちらにせよ大量のサンプルと申告者を持っているサービスは有利になるので、個人レベルならば例えば「Gmailへフォワード→POP3で取得」などという方法を使うのも手かもしれない。

1  Re: IMAP filtering, how to mark my own messages read

メールを procmail で imap 用 Maildir フォルダに振り分ける際、一部メールに関しては最初から既読に出来ないものかと調べてみたら、Re: IMAP filtering, how to mark my own messages read と言う方法が見つかった。
Maildir ではファイル名で未読・既読状態等を管理しており、基本的には cur/ ディレクトリに :2,S と言う名前で終わっていれば既読とみなされる。そこで

:0
* conditions
{
  foldername=whatever

  :0c
  .$foldername/ # stores in .$foldername/new/

  :0
  * LASTFOLDER ?? /\/[^/]+$
  { tail=$MATCH }

  TRAP="mv $LASTFOLDER .$foldername/cur/$tail:2,S"

  HOST
}

のようなルールで、特定 conditions の場合に mv コマンドでファイル名を強制的に書き換えてしまう TRAP (procmail 実行終了時に実行される処理) を仕込む。直接 new/ から cur/ に mv をかけるあたりも Maildir の思想を完全に否定しているし、結構乱暴な方法ではあるけど、普通に使う分にはこれで問題になることはあまり無さそうなので、まぁ用には足るんじゃなかろうか。
procmail 以外の振り分けソフトならもっとスマートな方法があるだろうか?

1  fml → mailman 移行メモ

メモ書き。mailman で予め listname でメーリングリストを作成し、必要な設定をしておく。メンバーの移行は普通に fml の /var/spool/ml/listname/members などから Webインターフェイス経由で登録。

アーカイブの移行は fml 付随の packmbox.pl を使い

# cd /var/spool/ml/listname/spool/
# perl /.../packmbox.pl > /tmp/listname.mbox
# mv /tmp/listname.box /var/lib/mailman/archives/private/listname.mbox/
# cd /var/lib/mailman/archives/private/listname.mbox/
# /usr/lib/mailman/bin/arch listname listname.mbox

だーっと過去メールが流れて html の index が作成される。閲覧権限には要注意。

mailman 1:2.1.9-9 では fml 風の [listname:01234] 的な通番付き Subject を作ることが標準で出来る。fml で使っていた通番をそのまま引き継ぐにはホームサーバー非定期日記（風） を参考に

# /var/lib/mailman/bin/withlist listname
listname のリストを読み込中 (ロック解除)
変数 `m' が mlname の MailList インスタンスです
>>> m.Lock()
>>> m.post_id = (/var/spool/ml/listname/seq より1多い数字)
>>> m.Save()
>>> m.Unlock()
>>> ^D
最終処理中 

とする。

1  Debian lenny での postfix + mailman install 備忘録 (専用サブドメイン利用型)

ここでは 素のドメイン名 (listname@example.com) ではなく、mailman 専用サブドメイン (@lists.example.com) を利用する。全ての専用サブドメイン宛メールは mailman が処理するものとして扱われる。サブドメインを使わず aliases を用いる方法は GNU Mailman インストールマニュアル 等を参照の事。

導入は例によって aptitude 一発で完了。

 # aptitude install mailman
...
 # dpkg -l mailman
ii  mailman        1:2.1.9-9      Powerful, web-based mailing list manager

導入時に利用する言語を聞かれるので、en と ja を選択し ja をデフォルトにしておく。ja で利用すると cli の日本語が euc-jp で出力されてしまい、utf-8 等の terminal 環境では文字化けするのが難だが、それ以外は特に問題ないようだ。

2  Postfix の設定

設定は /usr/share/doc/mailman/README.Debian にある通り、/etc/mailman/postfix-to-mailman.py の記述に従う。

/etc/postfix/main.cf

    relay_domains = ... lists.example.com
    transport_maps = hash:/etc/postfix/transport
    mailman_destination_recipient_limit = 1

/etc/postfix/transport

lists.example.com   mailman:

これで @lists.example.com 宛のメールは全て postfix の mailman service に渡される。mailman service は master.cf で定義される。lenny では external service として標準で入っていた。

/etc/postfix/master.cf

mailman   unix  -       n       n       -       -       pipe
  flags=FR user=list argv=/usr/lib/mailman/bin/postfix-to-mailman.py
  ${nexthop} ${user}

/etc/mailman/mm_cfg.py は以下のようにする。

MTA = None # No MTA alias processing required
# alias for postmaster, abuse and mailer-daemon
DEB_LISTMASTER = 'postmaster@example.com'

MTA = Postfix での alias 共有は利用しないので注意。

3  Webインターフェイスの設定

apache では特定の VirtualHost でのみ mailman interface を表示させたいので、sites-available/lists.example.com に以下の行を入れる。

Include /etc/mailman/apache.conf

URL から /cgi-bin/ を省略したい場合は /etc/mailman/mm_cfg.py を以下のように設定しておく。

DEFAULT_URL_PATTERN = 'http://%s/mailman/'

併せて /etc/mailman/apache.conf も編集

ScriptAlias /mailman/ /usr/lib/cgi-bin/mailman/

この設定をする前にメーリングリストを作成した場合は、メーリングリスト個別の設定の方も変更する必要があるようだ。

4  短いドメインパート形式への対応

ちなみにこうした @lists... を使う設定の上で listname@example.com のように lists. を省いたメールアドレス形式を使いたい場合、当該 listname のメールアドレスやそれに付随する listname-action@ コマンドメール類を @lists. へ流し込む virtual map / regexp virtual map を書く必要がある。後者には postfix-pcre が必要。

/etc/postfix/virtual

listname@example.com  listname@lists.example.com

/etc/postfix/virtual_regexp

/^(.+)-(unsubscribe|off|leave)@example\.com$/ $1-$2@lists.example.com
/^(.+)-(post|admin|request|owner|join|leave|confirm)@example\.com$/ $1-$2@lists.example.com

メールアドレスを regexp match させての処理は色々と危険なので、動作を理解していない場合はやらない方がいいだろうし、新しい list を作る度に virtual の方は編集が必要だし、こんなケレン味のある方法より素直に aliases/virtual を使った方がいい気もするが、まぁ移行上の都合と趣味の問題ということで。

1  メールサーバの再移行

先月前半にトラブルがあった際にメールサーバだけ一時的に他所に移していたが、ハードウェアを更新した後は特に問題なく稼働しているので、新サーバに再移行した。今回のサーバ移行手順は以下の通り。

1. 旧サーバの設定・メール・HOMEを新サーバに移行
2. 新サーバで一通りの MTA 設定等を完了して稼働開始
3. 現サーバの MTA を停止 (セカンダリMXサーバはそのまま稼働)
4. 現サーバの Maildir 内メールを新サーバにrsync
5. DNS で Primary MX の Aレコード向け先を現サーバから新サーバに切り替え
6. 外部 MTA 及びセカンダリMXから新サーバに向けてメールが流れ出すのを確認

作業は昨晩 0時には完了。spamd が動いてなかったり、 courier-imap/pop3d & cyrus-saslauthd を dovecot に移行統合したりした都合で幾つか小さな問題はあったが、特に大きな問題なく移行できたと思う。特に設定に変更は無いはずだが、パスワードが旧サーバのものに戻っているので注意されたし。利用者・メール送信者で不具合がある人はご連絡ください。なおメーリングリストは fml から mailman に移行した上で近日中に動かします。

1  sendmail でのセカンダリMX設定 備忘録

以前使っていたセカンダリMXが使えなくなっていたのを放置していたので、某サーバの sendmail を設定した備忘録。基本的な考え方は

1. DNS の MX レコードに primary より大きな数字の MX として FQDN を登録
2. 自分が第三者から受け取って relay していいドメインを設定する
3. relay 先の static な経路として primary サーバを指定する

DNS にはセカンダリMXに使うサーバを数字の大きな MX で登録する。

mydomain.example.com.   IN MX 10 mail.mydomain.example.com
mydomain.example.com.   IN MX 20 secondarymx.mydomain.example.com

sendmail 側の設定は、概ね NETWORKWORLD Online - メールサーバ運用管理 一問一答！ 第2回 の通り。リレー配送を許可するドメインは /etc/mail/relay.domains に記載。

mydomain.example.com

primary サーバへの配送は sendmail.cf で mailertable の設定が有効になっていない場合は .mc から以下の設定を組み込んだ上で cf を再構築しておく。

FEATURE（`mailertable', `hash /etc/mail/mailertable'）

/etc/mail/mailertable にて

mydomain.example.com smtp:[mail.mydomain.example.com]

のように記載し、db を構築

# makemap hash /etc/mail/mailertable.db < /etc/mail/mailertable

その後、sendmail を再起動。設定後は 3rd relay の設定等を色々と確認しておこう。

2  secondary mx に溜まったメールの強制配送

mailq にメールが溜まっている場合、sendmail で mailq を flush するには

# sendmail -qf

を実行する。基本的には queuerunner が自動的に再送信してくれるので、急ぐとき以外は実行する必要はない。

1  3分LifeHacking：PC内にメール送信サーバを設置する - ITmedia Biz.ID

5,6年前ならいざ知らず、 今更こんな記事を得意気に lifehacking と言って載せる気持ちが分からない。

つまり自分のPC内にSMTPサーバを設ければ、普段使っている電子メールサーバが動かなくてもメールを送信することは可能だ。3分LifeHacking：PC内にメール送信サーバを設置する - ITmedia Biz.ID

動的IPアドレスを使うアクセス回線からの SMTP は、ISP によってはそもそも OP25B で外に出て行けない仕組みになっているところが増えてきている。 使っている回線に OP25B が無い場合でも、 相手のメールサーバ側が IP25B で拒否してくる場合もある。 更に自分のメールドメインが SPF や DomainKeys などのサーバ認証を行っている場合、 自PCからの送信が「ドメイン詐称」として無条件で spam 判別されるリスクもある。 また動的IPアドレスからのメール送信は、エラー時のハンドリングなどに潜在的な問題があり、可能な限り避けるべきだ。

ではどうすべきかだが、 Gmail のように SMTP Auth で認証可能かつ Submission port (587/tcp) を開けているサービスに relay させるのが正しい。 Webメールのインターフェイスを使ったり、企業ユーザであれば VPN を利用する手もあるだろう。

安易に自分の PC に SMTP サーバソフトなぞ入れる前に、自分の使っている ISP やメールサービスのメール送信機能を調べるのが先決だ。

1  クライアントサイドでのSPF対応

MTA である postfix レベルで SPF による受信拒否をするのは現状やりすぎだが、 spam filter のレベルで判定基準の一つにする手はある。 特に「本当ならばSPFレコードが提供されているドメインで、SPFレコードのIPアドレスと送信元サーバのIPアドレスがマッチしない」と言うケースであればほぼ黒といえる。 また逆に、SPF を通ったのであれば spam スコアを軽減できる可能性もある。 後者は spammer が SPF 対応してくることを考えると微妙だが。

Spamassassin で SPF を使うには、単に /etc/spamassassin/init.pre にて

loadplugin Mail::SpamAssassin::Plugin::SPF

として SPF verification test Plugin を呼ぶ。 最新版では最初から有効になっているが、 Debian で使うには libmail-spf-query-perl を入れるか、Mail::SPF を別途入れる必要がある。 前者は Recommends には入っている。 個々の設定で

whitelist_from_spf *@docomo.ne.jp

のようにして、whitelist に登録した from アドレスの送信サーバが詐称されていないことを確認することも出来るようだ。

もちろんこの先 spammer が SPF に対応してくる可能性もあるが、その場合は spam と送信元の紐付けが SPF で一意に出来るので IPアドレスレベルでフィルタしやすくなるわけで、SPF 自体が無意味になるものではない。

1  スラッシュドット ジャパン | NTTドコモがSPFによるメール着信拒否機能を提供

ユーザの選択によるものだそうだが、メールマガジンなど一律で送信するようなサービスでは対処が必須になりそうだ。au では既に同様の機能が提供されているようなので対処が終わっている所が多いのかもしれないが。

SPFは、基本的には DNS サーバの TXT レコードに送信メールサーバを規定のフォーマット、例えば docomo.ne.jp の場合は

v=spf1 +ip4:203.138.203.0/24 ~all

のように書き込めばいいので対処は難しくはない。 とは言え先日 TXT レコードを登録できるDNSサービスは意外と多い? で書いたように、増えてきたとはいえ未対応の業者も多く、実際問題として init.org を登録している NSI のDNSサービスは TXTレコード登録・編集に対応していない。 ドコモや au のような取り組みが NSI 等にもプレッシャーになってくれればありがたいのだが。

1  /var 溢れと postfix のエラーメール

今朝方にどうも attack を受けたらしく、 /var/log/mail.log が肥大して /var が溢れたようだ。Maildir を /var とは違うパーティションの /home に配送しているのでメールロストは無かったが、Postfix からエラーメールが大量に届いていた。

Subject: Postfix SMTP server: errors from xxx.jp[219.xx.xx.xx]
--

Transcript of session follows.

 Out: 220 one.init.org ESMTP Postfix
[snip]
 In:  MAIL FROM: <fuckinspam@example.com>
 Out: 452 4.3.1 Insufficient system storage

Session aborted, reason: lost connection

Insufficient system storage がなぜ出るのか気づかなくてしばらく色々さまよってしまったが、apt の cache 削除と logrotate をかけて対処。どうも daily/weekly の logrotate が正しく回っていない感じだが、何故だろう。

1  POP over SSL で証明書の多くがオレオレである理由

それにしても、上のオレオレ事業者たちは、なぜ普通にサーバ証明書を買わないのだろうか？高木浩光＠自宅の日記 - APOP終焉で「POP over オレオレSSL」の撲滅運動が可能に

VeriSign がサポートしていないからでは? GeoTrust ではクイックSSLプレミアム等がサポートしているけど、最大手の VeriSign では基本的に Web 用 SSL証明書しか販売してない。使っちゃいけないということでは無いはずだけれど、公式なサポートが無いものはビジネスではかなり使いにくい。

2  POP over SSL は必ずしも公式な証明書が必要なわけではないが

そもそも不特定多数のユーザ対不特定多数のWebサーバという図式の HTTPS と違い、POP over SSL (や、MUA→MTA/MSA間の SMTP over SSL) の場合、公式認証局の証明書である必要自体は無い。証明書が正しいことを確認出来さえすれば、それを一度インストールしてしまえば問題が無いからだ。つまりは例えば Fingerprint が印刷された紙でも郵送するなり、正式な証明書を用いた https のサイトに証明情報と手順を出しておけば済む。と言うわけで POP over SSL に関して言えば「オレオレ証明書」が必ずしも悪とは限らない。

もちろん例として挙げられているような「証明書のチェックを無視する」と言うのは DNS poisoning や Man in the middle attack に対して無力なのでやるべきではない。また一般ユーザのレベルを考えれば、多少でも手順を省くために公式な証明書を使うのはよいアイディアなのは確かである。しかし VeriSign がサポートしていない現時点ではなかなか難しいだろうし、そもそも残念な事に大多数のユーザは今も over SSL や APOP どころか平文 POP3 を使っているというのが現実だったりするので、まずはそのあたりから始めないとなんともならないのではなかろうか。

まぁ POP over SSL を使っても peer to peer で暗号化されるわけでは無いので、どこまで注力すべきかというのは(パスワードの暗号化をのぞけば)微妙な気もしているが。

1  procmail がメーリングリストを FROM_DAEMON で引っかける件に付いて調べた

.procmailrc に FROM_DAEMON ルールを書いておくとやたらと普通の ML が引っかかるなと思ってソースを見てみたら、config.h 内の FROMDsubstitute にある正規表現のうち

Precedense:.*(junk|bulk|list)

fml の Precedense デフォルトは list だから、これがヒットしているようだ。メールマガジン等で Precedense: bulk で送ってきているものも同様にヒットしている。ちなみに正規表現全体はこう。

#define FROMDsubstitute "(^(Mailing-List:|Precedence:.*(junk|bulk|list)|\ 
To: Multiple recipients of |\ 
(((Resent-)?(From|Sender)|X-Envelope-From):|>?From )([^>]*[^(.%@a-z0-9])?(\ 
Post(ma?(st(e?r)?|n)|office)|(send)?Mail(er)?|daemon|m(mdf|ajordomo)|n?uucp|\ 
LIST(SERV|proc)|NETSERV|o(wner|ps)|r(e(quest|sponse)|oot)|b(ounce|bs\.smtp)|\ 
echo|mirror|s(erv(ices?|er)|mtp(error)?|ystem)|\ 
A(dmin(istrator)?|MMGR|utoanswer)\ 
)(([^).!:a-z0-9][-_a-z0-9]*)?[%@>        ][^<)]*(\(.*\).*)?)?$([^>]|$)))"

微妙なのもあるから、適当に切り出して自前のルールを作るのがいいか。

1  taRgrey - S25R + tarpitting + greylisting

以前 postfix + Rgrey での spam 対策 で参考にさせてもらった Rgrey の stealthinu さんが、postgrey の greylist に tarpitting を追加した物を公開したと、以前メールで教えていただいた。

taRgreyとは、メールサーバ上でスパムやウイルスメールを排除するためのフィルタの手法で、 S25Rとtarpittingとgreylistingというスパム判定手法を組み合わせて使うというものです。
S25Rにより、動的IPっぽいFQDNからの接続からは怪しいと判断し、tarpitting(応答の遅延)を行います。tarpittingを待ちきれずに送信元が接続を切った後、再度送ってきた場合にはgreylisting(再送のチェック)により救済します。S25Rとtarpittingとgreylistingと、全てのフィルタを抜けれなかったものだけがスパムとして排除されます。taRgrey - S25R + tarpitting + greylisting

大分前に導入しているのだが、しばらく利用しての効果をまとめておく。

Debian には postgrey パッケージがあるのでこちらの導入は簡単なのだが、targrey を使うためには postgrey に patch を当て、設定を変更する必要がある。導入手順は元サイトを参照してほしいが、流れは概ね以下の通り。

1. postgrey に patch を当てる
2. /etc/default/postgrey の POSTGREY_OPTS に tarpit, targrey 等の設定を追加
3. /etc/postfix/permit_client_nots25r を追加
4. /etc/postfix/main.cf を編集

以前 Rgrey を導入するために設定変更している状態に更に手を入れることになったので、状況を把握するのが多少手間取った。ロジックとしては smtpd_recipient_restrictions で S25R をチェックし tarpitting を適用、tarpitting で失敗した後に再送してきた相手は smtpd_data_restrictions の方で greylisting のチェックをかけている。postgrey はその辺りを db に保存して、状態遷移を管理しているようだ。

taRgrey では tarpit で失敗した分を greylist で救う形 (tarpitting || greylist) になるため、greylist や tarpitting 単体よりは条件が多少緩くなる。その分 false positive は経るだろうが false negative が増えるかもしれない。逆に厳しくしたいのならば、条件を (tarpitting && greylist) にすればよい。

2  taRgrey の効果

1月16〜31日の約2週間の効果を以下に記す。postgrey のオプションは taRgrey で推奨されている --tarpit=65 --targrey --delay=1200 --retry-count=2 をそのまま用いている。

処理	処理数	残通数
SMTP総コネクション数	79,863	79,863
header_checks での添付(.pif .scr)DISCARD	4,026	75,837
HELO Blacklist/Rule によるREJECT	5,988	70,349
S25RにマッチしてのWARN	63,940	5,909
→ RCPT Blacklist によるREJECT	15
→ その他ルールによるREJECT	10,046
→ tarpitting での lost connection	16,511
→ Gleylisted による REJECT	32,882
taRgrey通過通数		8,109

数字が合わない部分があるが、ログをラフに解析した結果なので大目に見てほしい。taRgrey 以外のルールで意外に効いたのがhelo blacklist による reject と、smtpd_recipient_restrictions の reject_unknown_sender_domain (5,234) 。user unknown での reject も 3,384 と結構多いので、virtmap や alias での catch all ( *@domain を特定アドレスに転送 ) は無い方がよさそうだ。

当サーバでは、taRgrey を抜けたメールはその後、Amavis-new + ClamAV によるフィルタを通過する。

AmavisでのBAN/BADH	2,144
Amavis通過通数		5,965

ちなみに Rgrey も適用していない去年6月の場合、amavis に到達したメール数が68,231、amavis で落ちたメール数は 24,320 、通過数が 43,911 と、どれも 10倍近い。メール本文スキャンによるサーバの負荷を考えると、かなりの負荷軽減になっていると考えられる。

最終的に各ユーザに落ちる際に、更に Procmail、SpamAssassin によるフィルタが適用される。

MAILER-DAEMONなど定型フィルタ	1,355
SpamAssassinでのフィルタ	3,787
最終的なメール数		823

最終的な spam スルー数(false negative)は2週間で5通、誤判定(false positive) はメールマガジン1通だった。false positive が低いのは、単に whitelist をきちんと書いているからかもしれない。非 spam メールのうちでは、「Virus 判定された」と From アドレス宛に返信してきているメールが結構多い。

単純に効果のほどを考えると、Debian では patch などがいらない postgrey での Rgrey だけでも十分かもしれない。もちろん taRgrey (tarpit || greylist) で false positive を減らしたい場合や、(tarpit && greylist) として厳しく受け付けたい場合などには、この組み合わせは有効だろう。

1  MXLogic Threat Center

米国の spam filtering ビジネス企業、MXLogic の Threat Center には、世界で動いている同社 spam フィルタ製品の判定情報が集計されている。それによると、「12% が普通のメール, 87.5% が spam, 0.5% が Virus」となっており、世に流れているのメールの実に 90% 弱が spam であると言う陰鬱な事実が示唆される。

同じく spam filtering サービス提供企業 Postini のPostini / Stats でも「84.8% が spam, 0.3% が Virus」と言う数字が出ており、日本に限ればまた数字が違うのかもしれないが、世界的にはこれくらいの傾向だと言うことが分かる。

さらに Postini の Directory Harvest Attacks (DHAs) という指標を見ると、世界のメールサーバの性能のうち更に 30〜50% が、spammer がサーバを乗っ取ったり情報を引き出そうという意図で仕掛けている攻撃に費やされている、と言うことも見て取れる。同社は「spammer が DHAs に成功してメールアドレスなどの情報を引き出した場合、そのアドレス宛の spam が目覚ましく増える」としており、SMTPサーバ側の情報漏洩対策 (VRFY, EXPN に応じない、安易に User Unknown を返さない等) も大事だと言うことが分かる。

メール到達後の spam filtering も相当な処理を CPU に強いている訳で、spam によって浪費されている全世界のコンピュータ資源・ネットワーク資源がどれだけあるかと思うと気が遠くなりそうだ。特に最近は Virus 感染 PC 経由での botnet からの送信も多いが、OP25B を採用する ISP が増えれば多少なりとも状況はマシになるだろうか。

1  ここ数ヵ月のメール流量推移が大きく上昇傾向

あまり具体的な数字は出せないのだが、某処メールサーバでのメール数がここ数ヵ月恐ろしい程増えている。半年前のざっと 3,4倍はきている感じ。Graylisting や Tapping をかけると結構な割合で落ちるので spam bot なのだろうけど、何か大規模な感染でもあったのだろうか。IPアドレス分布はあまり真面目に調査していないが、ざっと見た感じでは全体的にばらけている。国としては米国・中国・韓国が相変わらず多いが日本もそれなりに。

1  さくらレンタルサーバのブラックリスト登録状況について - Open MagicVox.net

さくらのレンタルサーバサービスが spam の発信源になっているらしいという話。

さくらインターネット管理下のほぼ全てのIPアドレスが、 spambag.org というブラックリストに載っているため、 相手にメールが届かない可能性があるが、さくら側では手の打ちようがないとのことでした。 さくらレンタルサーバのブラックリスト登録状況について - Open MagicVox.net

私が使っているサーバも見事に Black List 入り。まぁメールサーバとしては使っていないのでそちらの影響は無いのだが。

以前に Load Average が 〜20になり続けた時には管理者に駄目元で連絡した後に回復したのだけど、多分あれも spammer のツールを停止するなりの措置を取ったということなのだろう。その後しばらくは落ち着いていたが、今日くらいからまた 〜15 程度の高負荷状態が続いている。

最近の風潮としては ISP 等による OB25B が取られはじめてきたため、一般回線を渡り歩いての spam 行為がやりづらくなったというのも、こうした固定IPアドレスのホスティングサービスが攻撃元として狙われるようになった一因なのかなと思う。ともあれ根本的になんとかしてほしいところだが、結局は個別にアカウント停止なりの処置を地道に続けるしかないだろうな。頑張れさくらのなかの人。

1  「25番ポートブロック」を2006年11月より順次実施 - ASAHIネット:プレスリリース

気づいていなかったが、9月22日のプレスリリースでASAHIネットも OP25B を適用する予定と発表していたらしい。

Q. 自宅サーバーを設置し、メールサーバーとして利用する場合、25番ポートブロックの影響を受けますか？

A. 固定IPアドレスをご利用の場合は影響はありません。ASAHIネット : よくあるご質問 （Q&A）

と言うことで、光回線なら無料/ADSLでは月額525円で使える固定IPアドレスオプションで使っている人は影響が無いようだ。うちは更に interlink MyIP を使っているのでそもそも影響を受けないはずだが。

それにしても普通、動的IPアドレスでメールサーバを立てようなんて人はいないよなぁ。と思うんだけど意外と見るんだよなこれが。DynamicDNS で運用なんてしてたら、IPアドレスが変わった瞬間に全然関係の無いマシンにメールが流れる可能性があるわけなんだけど、それはいいんだろうか。

1  相変わらず「ウィルスが含まれています」メールが From 宛に届く

最近では多くのメール受信サーバでウィルスチェックが動いている。特に商用サービスや企業では殆ど全てで動いている状況だと思うが、未だに「あなたが送ったメールにはウィルスが含まれています」と言う警告を From に書かれたアドレスに投げてくれるシステムが多い。

From なんていうのは大抵の場合ウィルスが書き換えて出すものであり、そこに警告を投げてもそれは実際にウィルスつきメールを送ったのとは別人である事がほとんど。つまり、そんなものを送られてもなんの役にも立たない。ましてやウィルスが添付されたまま送りつけてきたり、元メールの envelope ヘッダを全て削って送ってくるのは嫌がらせ以外のなにものでもない。

そう言うわけで心当たりのある管理者の方々はそうした自動返信を停止してくれるようお願いしたく。せめて Mailer-Daemon からのメールにしてくれればフィルタしやすいんだけど、完全独自形式で送ってくる人は強く反省してください。

1  nobilog2: Stupid Networkと25番ポート

この記事を読んであれれと思った。

迷惑メールの受信は自分でアプリケーションで防御すればいいだけの話だが、送信となると他人に迷惑をかけることになるし、同じ話じゃない、という人もいるかもしれない。
　しかし、それにしたってBIGLOBEのSMTPサーバーのポートを変えるとか、認証サービスを使うとかしてくれればいいわけであって、25番ポートを閉じるのはおかしい。nobilog2: Stupid Networkと25番ポート

BIGLOBEのSMTPサーバのポートを変えたり認証サービスを使うことの何がこの問題の解決になるのかが全くイメージできなかった。世ではもしかして、 OP25B がなんの目的で実施されているのかあまりよく知られていないのだろうか。

2  OP25B とはどういったものか

OP25B は 、ISP の回線契約者(主に動的IPアドレスの利用者)に対して、自 ISP メールサーバ以外への port 25 宛通信を遮断する措置を言う。最近はウィルスを仕込まれた PC を利用した、いわゆる botnet からの迷惑メール送信も非常に多いため、こうした回線契約者からの spam 送信は非常に多い。

OP25B により、「ISPの回線(ADSL, Bフレッツ等)契約者が、動的IPアドレスから他のメールサーバ(の25番ポート)に大量のspamを送りつける行為」を抑制することができる。解説としては IAJapan の OP25B 解説 がわかりやすい。

3  ISP が OP25B を適用する理由

昨今では、こうした回線契約からの送信者を放置するとそのISPは「spam業者を野放しにしている」と言う非難を受けるため、特に携帯メール向けに関しては OP25Bを実施しているISP が大半になってきている。

そもそも動的IPアドレスからのspamは、IPアドレスが頻繁に変わるという性質上、メール受信サーバ側では個別IPアドレスでの拒否設定がしにくい。勢いどうなるかというと、そのISPの利用しているIPアドレスブロック全てをまとめて拒否、という処理を取られかねず、実際に海外の ISP が日本の ISP のメールを全て遮断してしまいトラブルになったケースもある。

4  OP25B によって影響を受けるユーザとその回避策

ちなみに通常のユーザは、例えば BIGLOBE の回線契約者なら BIGLOBE回線からBIGLOBEのSMTPサーバを送信サーバとして設定するはずで、その場合はport25でも送信できるようにしてある事が多い。ISPからすれば、自社のSMTPサーバを経由してくれる分には外部への流量制限やリレー遮断をすることが出来るため、迷惑メールの遮断もやりやすい (OP25B+流量制限しておいて「大量送信は別料金で承り」なんていう商売の ISP もあるのはどうかと思うが…)。

外部のISPのメールサーバやホスティング先サーバ、会社のサーバ等を MTA として使いたい場合には、RFC2476 で定められた Submission (587/tcp) port の利用が推奨される。
Submission(587) の方では認証のない接続を一切受け付けないようにすれば、spammer が Submission めがけてメールを投げてくると言うリスクは排除できる。POP before SMTP では「ユーザ」ではなく「IPアドレス」の認証のため、認証強度(?)が弱いため、最近の認証には SMTP-AUTH を利用するのが一般的だろう。

元々、SMTPが「メールサーバ間(MTA)」と「クライアントからのメールを受け付ける(MSA)」と言う別の役割で同じポートを使っていると言うのがそもそもの問題だという話もあり、と言ってもインターネットのようなものでは現状の仕組をいきなり変えるわけにもいかないので、議論しながら変えていくことになるのだろう。

5  ISP は土管であるべきか

OP25B は結局のところ ISP が自衛のためにやる事なので、ISPが代替手段を用意しろというのも一理ある。とかく固定IPアドレスが高いISPが多すぎるわけで、無料で固定IPアドレスを提供している国内ISPなんて ASAHIネットくらいしか思い付かない。また Submission port にしても世間的に十分普及しきっているとは言いがたい。

そういうこともあり、以下の部分

これらの意見には、私もまったく同感で、ISPも含めたインフラ部分には「Stupid Network」に徹して欲しいと思うnobilog2: Stupid Networkと25番ポート

ISP回線土管主義には私も基本的に賛成だ。とは言え ISP にしても、こうした制限をするためには追加機器の導入なり余計なサポートの発生なり規約の改定なりのコストをかける必要があり、喜んでやるような話ではない。spam と言う悪に対しての必要悪だと言える。

将来的にこうした上流でのコントロールが行きすぎてしまうのは確かに問題になりうるが、日本での話に限れば、現実にはいわゆる「通信の秘密」を基本とする総務省の意向的にも、あまり面倒な制御は ISP でも現状やりにくいと言う事情もあり、さほど心配するような問題では無いと思う。

1  Rgrey - S25R + greylisting

postfix に Rgrey の方法で smtp spam filtering を入れた。ささださんの真似。1日動かした時点での効果としては、amavis の bannedmail フォルダに落ちるメールが、約 1/10 に減少している。spam filter で spam フォルダに落ちるメールは 1/3〜1/4程度になった。これだけで spam を遮断することにはならないが、後段の amavis や spamassassin に比べて処理がかなり軽いので負荷軽減にもなる。

2  Greylisting + S25R

基本的な発想は Greylisting と言う方法。

一定時間が経過するまで一時拒否(4xx)して、それでも接続してきたら、たぶんopen proxyじゃないと思われるので受け取ることにしよう。

つまり「smtp 接続に 450 (一時的な拒否) を返して再送要求すると、まともな MTA なら再送するけど spam tool や virus は再送しないから spam を遮断できる」というもの。一度再送が行われた IPアドレスと From, To の組合わせは記録され、1ヶ月間は再度の再送要求無く処理される。

しかしこれだと「でもそれってまともな MTA にも余計な負担をかけるよね」と言われるのももっともな話。「じゃあ怪しげな接続元だけにこの手を使おう」と言うことにして、S25R にあるような

有効なスパム対策は、メール中継サーバからのSMTPアクセスを受け入れる一方で、エンドユーザー用回線からのSMTPアクセスを拒絶することである。それらは、IPアドレスの逆引き名の特徴に基づいて識別できる。

に基づき、「逆引き出来ないか、逆引き結果がいかにも回線系サービス」のものに Greylisting を適用する。

こうした接続元逆引きパターンによる判別は、postfix の場合は main.cf の設定のみで対応出来る。設定内容は rgrey そのままだが、一応書いておくと

/etc/postfix/main.cf

 smtpd_recipient_restrictions = ... , regexp:/etc/postfix/check_client_fqdn
 smtpd_restriction_classes = check_greylist
 check_greylist = check_policy_service inet:60000 

/etc/postfix/check_client_fqdn

 /^unknown$/                                  check_greylist
 /^[^\.]*[0-9][^0-9\.]+[0-9]/                 check_greylist
 /^[^\.]*[0-9]{5}/                            check_greylist
 /^([^\.]+\.)?[0-9][^\.]*\.[^\.]+\..+\.[a-z]/ check_greylist
 /^[^\.]*[0-9]\.[^\.]*[0-9]-[0-9]/            check_greylist
 /^[^\.]*[0-9]\.[^\.]*[0-9]\.[^\.]+\..+\./    check_greylist
 /^(dhcp|dialup|ppp|adsl)[^\.]*[0-9]/         check_greylist

postgrey は Debian なら公式パッケージが用意されているので apt 一発。と言うことで導入は容易だ。check_client_fqdn の正規表現は色々試してみるのが良さそうか。

3  導入雑感

結局これは逆引き名が「怪しい」サーバに負担を強いることになるが、実際の効果がそれなりにあるのと 1度再送してもらえば当分はスルーするので許容できるレベルではなかろうか。将来的には OP25B で解決される部分ではあるが、全ての ISP がそれを行うわけでもなかろう。ちなみに現在うちの MTA では Rgrey の他にも NS による Reject や 添付ファイル(.scr|.pif)の拒否もしている。MTA での総合的な spam 対策は spam対策まとめ が詳しい。

1  postfix で submission (587/tcp) を待ち受ける

最近 Outbound port 25 Block を適用する ISP が増えてきた。うちは固定IPで運用しているが、万が一ブロックされた場合でも他 ISP からうちの MTA を経由してメール送信ができるように submission port (587/tcp) を空けておくことにする。と言っても /etc/postfix/master.cf に以下の行を追加して /etc/init.d/postfix reload するだけ。

submission inet n - - - - smtpd

jail の有無などで多少設定に違いがあるが、基本的には同じファイルにある smtp の設定と揃えておけば良いと思う。利用時には SMTP-Auth 等、認証を忘れずに。

2  RelayHost + SASL Auth で ISP の MTA を経由した送信を行う

なお自分のサーバが動的IPアドレスである等の理由でサーバからの送信時に OP25B によるブロックを受ける場合は、ISP のメールサーバに対して Client SASL の設定をして認証可能にした上で relayhost として利用するといいようだ。