Contents
1. お馴染さん方式の効果
- ゆっくり返答することで多くの spam ホストは送信をあきらめます。
- 一時エラーで送信をあきらめるホストはさらに増えます。
2. お馴染さん方式の検討
お馴染さん方式 で 再接続の状況をしばらく観察していると、 いくつかの課題と対策方法が見えてきました。
2.1. エラー時に(RFC の推奨を無視して)直ちに再接続してくるホスト
spam とは限りませんが、spam 送信ホスト扱いにして拒否します。 なんどでも拒否するだけですが、再接続を繰返されると相手するのも手間です。
別のホストからすぐに接続してくるものもあります。
SPF, DMP, RMX などの別の対策法の普及が待たれます。
2.2. 複数のホストから送ってくる spammer
ひとつの接続をエラーにすると別のホストから接続してきます。 お馴染さん方式で拒否できます。
2.3. 複数の配送用サーバから送信してくるプロバイダ
複数のメイル配送用サーバをもち、別のホストから再接続してくるドメインからの場合、 おなじサーバを使って送られてくるまで、メイルは受信されません。 遅延が大きくなる可能性があります。
こういうドメインの数は多くはないので、判明するたびに(調査して) メイルホワイトリストに登録しています。 (ドメイン名で登録したり、/24 で判定することも検討しています。) このリストは共用するという方向で解決できるでしょう。 spam/SPF などが普及すれば、それを使うのがいいでしょう。
2.4. 受信してしまう spam
大規模プロバイダの送信サーバから送られてくるのは困りものです。 送信 IP アドレスだけでは判別できません。
IP アドレスで「いちげんさん」ホストかどうかを区別しているので、 メイルホワイトリストにあるホストから送信される spam は受信してしまいます。 メイリングリストが送ってくる spamなども含まれます。 (メイリングリスト管理者に報告しましょう。) 受信数が少なければ、手動で削除するので間にあうかもしれません。
より細かい制御が必要になるなら、Greylistingを使ってみましょう。 Greylisting では mail from, received to を利用した spam 拒否ができます。
2.5. spam でないのに再送してこないホスト
yahoo のサーバなどです。 RFC を守って再送するように改めてもらいましょう。
2.6. 送信時に call back してくるホスト
こちらから送信しようとするときに、相手も spam ホスト判定のために こちらに SMTP 接続してくることがあります。
これを拒否すると、相手がこちらからの接続を拒否して、 メイル送信ができなくなります。 最低限、SMTP 接続だけは受入れるようにします。
相手の IP アドレスをホワイトリストに登録しておくのが確実です。
3. 考察
通常メイルのような RFC 821/2821 に準拠した再送方式にspammerが対応してきたらという[../議論]もあります。
spammer が帯域を余分に使うだけだとかいう議論もあります。 こちらはそれが目的です。帯域の使いわけは SMTP だけの問題ではありません。
RFC に準拠した振舞いをするメイル(中継)サーバが spam を送ってくる場合にはブラックリスト検索してみましょう。 ブラックリストになければ、登録しましょう。
3.1. spam でないのに再送してこないホスト
RFC を守って再送するように改めてもらいましょう。
3.2. 初めての相手からのメイルが多少遅れることは許容できるはずです
許容できないのであれば、メイル以外の連絡手段を使ってもらいましょう。
一時エラーを返事するのをやめて、throttling だけで運用できるかもしれません。
3.3. 複数の受信サーバをもつドメインでの利用
受信サーバが複数あるドメインでは短期的受信リストを共用する必要が でてきます。 実装が簡単なことが特徴のお馴染さん方式でデータベースを利用するのは おおげさに思えます。
複数サーバを持つ理由が負荷分散であるなら、『メイルキューを持たないゲートウェイ』を使うことを提案します。
複数のサーバで信頼性が上がると思っておられるなら、 [http://www.star.le.ac.uk/~tjg/mail/fallback.html Fallback MX Considered Harmful]] を読んで、 ご自分の環境ではどうなのかを考えてみてください。
3.4. (RFC を無視して)再送を続けるホスト
SMTP/恒久的エラーを返事しても(RFC を無視して)再送を続けるホストがあります。 現在は tcpserver で接続拒否(deny)の設定をしています。
この場合、ルータで捨ててしまうのがお勧めです。 いずれブラックリストとして公表します。
3.5. spam 送信ホスト
spam を送ってくるホストが spam の発信に対してどの程度関与しているのか、 知ることも重要です。
かつては(善意の)第三者メイルの中継ホストがよく使われていました。 [http://spam.h1r.org/openproxy.html open proxy]] もあるそうです。 安易なパスワードを使っている SMTP AUTH リレーが狙われているそうです。
最近はダイアルアップや ADSL などの動的 IP アドレスを持ったホストから 直接送られてきています。
spammer を支援していたり、spam 送信を仕事にしている ISP も存在しています。 helo, "mail from" などでの詐称を許さない仕組みをひろめて、 spammer を封じこめることも重要です。 (SPF など)
[http://spam.h1r.org/blacklists.html DNS 経由でこれらのホストの情報を提供しているデータベース]]
4. 課題
ホワイトリストが簡単に作成できるといいのですが。
「いちげんさん」を待たせる時間をなるべく長くするのがいいという説があります。
- 協調型のブラックリストに登録される可能性が増えるからです。
spam に対抗するにはメイル利用者の協力が重要です。 spam を検出したら、 すぐに協調型ブラックリストへ登録するなどの対応をしたいものです。
[http://yro.slashdot.org/comments.pl?sid=48218&cid=4905447 whitelists aren't an answer]] という議論もありました。