手動でホワイトリストを作るのは面倒ではあるが、利点もある。スパムに対する防御力が強いことである。
以下は、私のサイトで観測されたアクセスである。
Jul 3 11:43:03 S010600e04cb1ea91.vf.shawcable.net [70.68.241.81] from=<nbxbfcxmp@…> …
Jul 3 11:48:14 S010600e04cb1ea91.vf.shawcable.net [70.68.241.81] from=<nbxbfcxmp@…> …
Jul 3 11:53:20 S010600e04cb1ea91.vf.shawcable.net [70.68.241.81] from=<nbxbfcxmp@…> …
Jul 3 11:58:26 S010600e04cb1ea91.vf.shawcable.net [70.68.241.81] from=<nbxbfcxmp@…> …
Jul 3 12:03:34 S010600e04cb1ea91.vf.shawcable.net [70.68.241.81] from=<nbxbfcxmp@…> …
約5分の間隔で“行儀よく”リトライしており、このようなアクセスはグレイリスティングを突き抜ける。しかし、人の目はだませない。送信者アドレスのユーザーIDがいかにも怪しいし、5回のトライで止まっていることから、スパムかウィルスに違いないと判断できる。このようなアクセスはけっこう見られる。
佐世保高専の中原さんのレポートによると、2006年に入ってからグレイリスティングを突き抜けるスパムが増えてきたので、素のS25R方式に戻したとのことである。正当なメールを受け損なわないためには相当神経を遣う必要があるが、手動のホワイトリスティングの方がスパムには強い。「怪しい」と見抜くことにかけては人間の判断力に勝るものはない。
単純なグレイリスティングに頼らずに、人間の知識と経験を活かしてホワイトリストの作成を自動化するというアプローチもある。東京外国語大学の芝野先生（「導入者の皆様の声」の7番）は、リトライ回数に加えてHELOアドレスと送信者アドレスとの整合性もチェックしてホワイトリストを自動作成するスクリプトを開発されている。
月曜日, 7月 31, 2006
日曜日, 7月 30, 2006
Rgrey
佐藤さんは、S25R方式にグレイリスティングを組み合わせたRgreyを作られた（qmail版のQgreyもある）。S25R方式の拒否条件に引っかかるホストに対して「450」を返し、リトライがあれば自動的に受け入れるというものである。postgreyにパッチを当てることによって実現している。
これにより、ホワイトリスト作成の手間がほとんどなくなる。大規模サイトには良いシステムである。リトライするスパムは通過できてしまうので、素のS25R方式（手動ホワイトリスティング）よりはスパムの阻止率は下がるが、約95%は阻止できると聞いている。
すでにグレイリスティングによってスパムの受信を十分に減らしているサイトでも、Rgrey（あるいはQgrey）の導入にはメリットがある。
素のグレイリスティングでは、初めてSMTPアクセスをかけてくるホストに対して無差別に「450」を返し、リトライしてきたホストをデータベースに登録する。したがって、膨大な数のまともなメールサーバがデータベースに登録されることになる。
それに対してRgreyは、S25Rの拒否条件に引っかかるホストに対してだけ「450」を返す。まともなメールサーバの大多数はS25Rの拒否条件に引っかからないので、グレイリスティングの対象にならずに通過できる。したがって、リトライさせられることによる送達遅れがなくてすむ。また、データベースが小さくてすむので、グレイリスティングサーバの負荷が軽くなるのである。
一方、スパムの阻止率は、素のグレイリスティングに比べてあまり下がらない。不正メールの送信元の約98%はS25Rの一般規則に引っかかるからである（2004年4月の統計による。論文参照）。
これにより、ホワイトリスト作成の手間がほとんどなくなる。大規模サイトには良いシステムである。リトライするスパムは通過できてしまうので、素のS25R方式（手動ホワイトリスティング）よりはスパムの阻止率は下がるが、約95%は阻止できると聞いている。
すでにグレイリスティングによってスパムの受信を十分に減らしているサイトでも、Rgrey（あるいはQgrey）の導入にはメリットがある。
素のグレイリスティングでは、初めてSMTPアクセスをかけてくるホストに対して無差別に「450」を返し、リトライしてきたホストをデータベースに登録する。したがって、膨大な数のまともなメールサーバがデータベースに登録されることになる。
それに対してRgreyは、S25Rの拒否条件に引っかかるホストに対してだけ「450」を返す。まともなメールサーバの大多数はS25Rの拒否条件に引っかからないので、グレイリスティングの対象にならずに通過できる。したがって、リトライさせられることによる送達遅れがなくてすむ。また、データベースが小さくてすむので、グレイリスティングサーバの負荷が軽くなるのである。
一方、スパムの阻止率は、素のグレイリスティングに比べてあまり下がらない。不正メールの送信元の約98%はS25Rの一般規則に引っかかるからである（2004年4月の統計による。論文参照）。
土曜日, 7月 29, 2006
個人サーバ
S25R方式に対して「ダイナミックIPアドレスの個人サーバをまるっきり無視している」という批判がある。まるっきり無視しているわけではないが、ダイナミックIPアドレスのサーバはスパム対策にはやっかいなのである。
S25R方式を導入した受信側サイトでは、ダイナミックIPアドレスのサーバからのリトライアクセスを発見したら、そのIPアドレスをホワイトリストに登録するだろう。ところが、送信側サーバがIPアドレスを変えたら、それもまた登録しなければならない。こうして1台のサーバのためにいくつものIPアドレスをホワイトリストに登録していけば、それらのIPアドレスのうちいずれかが、スパマーのコンピュータやウィルス感染したPCやゾンビPCに割り当てられて、そこからスパムやウィルスを受信してしまうおそれがある。
事情は、グレイリスティングを採用しているサイトでも同様である。グレイリスティングでは、初めてメールを送ってくるホストを一度「450」で蹴るが、二度目には受信して、その後は同じホストからの送信をすぐに受け入れる。したがって、ダイナミックIPアドレスのサーバによっていくつものIPアドレスに対して穴が開けられ、不正メールの受信のリスクが増えるのである。
今、OP25B（Outbound Port 25 Blocking）を導入するISPが増えつつある。ダイナミックIPアドレスのサーバから外へメールを直接送信することができなくなる。どのみち、ISPのメールサーバを経由して送信するか、固定IPアドレスのサービスに乗り換えるか、いずれかの策が必要になる。そうしてもらえれば、S25R方式を導入しているサイトにとっても助かる。受信にまったく問題なくなるか、あるいは1サーバにつき1件のホワイトリスト登録ですむからである。
S25R方式を導入した受信側サイトでは、ダイナミックIPアドレスのサーバからのリトライアクセスを発見したら、そのIPアドレスをホワイトリストに登録するだろう。ところが、送信側サーバがIPアドレスを変えたら、それもまた登録しなければならない。こうして1台のサーバのためにいくつものIPアドレスをホワイトリストに登録していけば、それらのIPアドレスのうちいずれかが、スパマーのコンピュータやウィルス感染したPCやゾンビPCに割り当てられて、そこからスパムやウィルスを受信してしまうおそれがある。
事情は、グレイリスティングを採用しているサイトでも同様である。グレイリスティングでは、初めてメールを送ってくるホストを一度「450」で蹴るが、二度目には受信して、その後は同じホストからの送信をすぐに受け入れる。したがって、ダイナミックIPアドレスのサーバによっていくつものIPアドレスに対して穴が開けられ、不正メールの受信のリスクが増えるのである。
今、OP25B（Outbound Port 25 Blocking）を導入するISPが増えつつある。ダイナミックIPアドレスのサーバから外へメールを直接送信することができなくなる。どのみち、ISPのメールサーバを経由して送信するか、固定IPアドレスのサービスに乗り換えるか、いずれかの策が必要になる。そうしてもらえれば、S25R方式を導入しているサイトにとっても助かる。受信にまったく問題なくなるか、あるいは1サーバにつき1件のホワイトリスト登録ですむからである。
金曜日, 7月 28, 2006
一般規則
私が作った一般規則は、なるべく多くのエンドユーザー回線を引っかけることができて、メールサーバを引っかけることがなるべく少ないように工夫したものである。作り上げるのに約10ヶ月かけた。逆引き名が一般規則に引っかかるメールサーバもあるが、少しくらいかまわないという考え方をとっている。送信をリトライしているうちにホワイトリストで救済すればよいからである。
しかし、Kさんの会社（「導入者の皆様の声」の4番）では、逆引き名の一般規則のうちルール6（逆引きFQDNの最下位の名前が「dhcp」、「dialup」、「ppp」、または「adsl」で始まり、かつ数字を含む）しか使っていないそうである。逆引きできるメールサーバを蹴るのを避けるためである。逆引きできないメールサーバはホワイトリストで救済し、逆引きできるエンドユーザー回線はブラックリストで拒否するという考え方である。
エンドユーザー回線からスパムやウィルスを送ってくる世界中のドメインをブラックリストに登録すると、ブラックリストは相当な大きさになると思う。しかし、マシンは高性能だし、運用のマンパワーにも不自由していないので、うまくいっているのだろう。
いろいろな考え方があってよいと思う。逆引き検査に基づいてSMTPを選択的に拒絶するのだから、S25R方式であることに変わりはない。
しかし、Kさんの会社（「導入者の皆様の声」の4番）では、逆引き名の一般規則のうちルール6（逆引きFQDNの最下位の名前が「dhcp」、「dialup」、「ppp」、または「adsl」で始まり、かつ数字を含む）しか使っていないそうである。逆引きできるメールサーバを蹴るのを避けるためである。逆引きできないメールサーバはホワイトリストで救済し、逆引きできるエンドユーザー回線はブラックリストで拒否するという考え方である。
エンドユーザー回線からスパムやウィルスを送ってくる世界中のドメインをブラックリストに登録すると、ブラックリストは相当な大きさになると思う。しかし、マシンは高性能だし、運用のマンパワーにも不自由していないので、うまくいっているのだろう。
いろいろな考え方があってよいと思う。逆引き検査に基づいてSMTPを選択的に拒絶するのだから、S25R方式であることに変わりはない。
ご厚意
「導入者の皆様の声」の4番で紹介しているKさんの会社では、社長命令で謝礼としてシャンパンを贈ってくださった。せっかくのご厚意なので、ありがたくいただいた。おいしかった。
社長がこんなに立派なお心の持ち主であればさぞかし良い会社だろうと思った。Kさんにお願いして会社を訪問し、お話を聞かせていただいた。社長自ら技術者からの提案を聞き、S25R方式の価値を認め、導入を判断されたそうである。出迎えてくれた人たちは皆、社長を信頼して生き生きと働いている様子であった。セキュリティ対策についての守秘を頼まれているので社名は明かせないが、本当に良い会社である。
Kさんほか皆様、その節はありがとうございました。
社長がこんなに立派なお心の持ち主であればさぞかし良い会社だろうと思った。Kさんにお願いして会社を訪問し、お話を聞かせていただいた。社長自ら技術者からの提案を聞き、S25R方式の価値を認め、導入を判断されたそうである。出迎えてくれた人たちは皆、社長を信頼して生き生きと働いている様子であった。セキュリティ対策についての守秘を頼まれているので社名は明かせないが、本当に良い会社である。
Kさんほか皆様、その節はありがとうございました。
木曜日, 7月 27, 2006
reject_unlisted_recipient
BBSで質問を受けた。退職したユーザー宛にメールマガジンを送ってくるサーバがS25Rの条件に引っかかってリトライを繰り返している。リトライのログを見ているのもわずらわしいが、User unknownを返すためにホワイトリスト登録するのもわずらわしい。そこで、クライアントアドレスチェックの前にUser unknownではねる方法はないだろうかということだった。
私は方法を知らなかったのだが、その人があとで自分で解決して教えてくださった。次のように設定すればよい。
smtpd_client_restrictions =
permit_mynetworks,
reject_unlisted_recipient,
check_client_access regexp:/etc/postfix/client_restrictions,
reject_unknown_client
私は、HELOアドレスが不正なアクセスと不正中継を要求するアクセスもついでに「554」ではねてしまおうと考えた。前回説明した、DRACによるPOP認証のデータベースの指定と併せると、次のような設定になる。
smtpd_client_restrictions =
permit_mynetworks,
check_client_access hash:/etc/mail/dracd,
check_helo_access regexp:/etc/postfix/helo_restrictions,
reject_unauth_destination,
reject_unlisted_recipient,
check_client_access regexp:/etc/postfix/client_restrictions,
reject_unknown_client
これで、私の拒絶ログソーティングスクリプトで表示されるのは、宛先アドレスが正しいアクセスだけになる。ホワイトリストに登録すべきホストを見つけるための監視がずいぶん楽になった。
私は方法を知らなかったのだが、その人があとで自分で解決して教えてくださった。次のように設定すればよい。
smtpd_client_restrictions =
permit_mynetworks,
reject_unlisted_recipient,
check_client_access regexp:/etc/postfix/client_restrictions,
reject_unknown_client
私は、HELOアドレスが不正なアクセスと不正中継を要求するアクセスもついでに「554」ではねてしまおうと考えた。前回説明した、DRACによるPOP認証のデータベースの指定と併せると、次のような設定になる。
smtpd_client_restrictions =
permit_mynetworks,
check_client_access hash:/etc/mail/dracd,
check_helo_access regexp:/etc/postfix/helo_restrictions,
reject_unauth_destination,
reject_unlisted_recipient,
check_client_access regexp:/etc/postfix/client_restrictions,
reject_unknown_client
これで、私の拒絶ログソーティングスクリプトで表示されるのは、宛先アドレスが正しいアクセスだけになる。ホワイトリストに登録すべきホストを見つけるための監視がずいぶん楽になった。
水曜日, 7月 26, 2006
POP-before-SMTP
POP-before-SMTPをサービスしているメールサーバにS25R方式を実装すると、ISPのエンドユーザー回線に接続された正当なクライアント（モバイルPCなど）からのSMTPアクセスがS25Rの拒否条件によって蹴られてしまう。これを解決するには、POP認証されたクライアントのデータベースをsmtpd_client_restrictionsパラメータとsmtpd_recipient_restrictionsパラメータの両方で参照すればよい。
たとえば、私が使っているDRACの場合は、以下のように設定する。ここで「dracd」が、POP認証されたクライアントのデータベースファイルである（実際のファイル名は「dracd.db」だが、「.db」を付けずに指定する）。
smtpd_client_restrictions =
permit_mynetworks,
check_client_access hash:/etc/mail/dracd,
check_client_access regexp:/etc/postfix/client_restrictions,
reject_unknown_client
smtpd_recipient_restrictions =
permit_mynetworks,
check_client_access hash:/etc/mail/dracd,
reject_unauth_destination
たとえば、私が使っているDRACの場合は、以下のように設定する。ここで「dracd」が、POP認証されたクライアントのデータベースファイルである（実際のファイル名は「dracd.db」だが、「.db」を付けずに指定する）。
smtpd_client_restrictions =
permit_mynetworks,
check_client_access hash:/etc/mail/dracd,
check_client_access regexp:/etc/postfix/client_restrictions,
reject_unknown_client
smtpd_recipient_restrictions =
permit_mynetworks,
check_client_access hash:/etc/mail/dracd,
reject_unauth_destination
火曜日, 7月 25, 2006
Rule 1 trap
一般規則のルール1（逆引きFQDNの最下位の名前が、数字以外の文字列で分断された2個以上の数字列を含む）に引っかかるメールサーバを持つ外国のサイトから苦情のメールが来たことがある。そこからのリトライアクセスを発見して、素早くホワイトリストに登録して受信した。
そのサイトから日本の某サイト（ドメイン名は伏せ字になっていたが、「.ne.jp」が付いていた）へ送ろうとしたメールに対する遅延警告メッセージが引用されていた。そこには「may not be mail exchanger」という見覚えのある文。これを作った張本人をネット検索で突き止めたのだろう。苦情は「分断された2個の数字をホスト名に含む正当なメールサーバがあることを考慮してくれ」というものだった。
私は、分断された2個の数字列をホスト名に含むエンドユーザー回線が多いことと、S25R方式をとるサイトでは拒否条件に引っかかるメールサーバをホワイトリスト登録しなければならないことを説明し、「貴サイトのホストを拒否しているサイトを教えてください。ホワイトリスト登録するよう私から言いましょう」と申し出た。
しかし、それっきり返事は来なかった。宛先サイトでもちゃんとホワイトリスト登録して、送達に困らなくなったんでしょ、きっと。
こういうこともあるので、ルール1は厳しすぎると思う人がいるであろう。実際、「3個以上の数字列」と条件を緩めて運用している人もいるようである。もちろん、人それぞれいろいろな工夫をしてくださってよい。
しかし私は、ルール1の条件の提案を変えるつもりはない。数あるメールサーバの中でルール1に引っかかるものは少ないが、「2個の数字列」という条件でスパムやウィルスメールが食い止められる頻度はかなり高いからである。
そのサイトから日本の某サイト（ドメイン名は伏せ字になっていたが、「.ne.jp」が付いていた）へ送ろうとしたメールに対する遅延警告メッセージが引用されていた。そこには「may not be mail exchanger」という見覚えのある文。これを作った張本人をネット検索で突き止めたのだろう。苦情は「分断された2個の数字をホスト名に含む正当なメールサーバがあることを考慮してくれ」というものだった。
私は、分断された2個の数字列をホスト名に含むエンドユーザー回線が多いことと、S25R方式をとるサイトでは拒否条件に引っかかるメールサーバをホワイトリスト登録しなければならないことを説明し、「貴サイトのホストを拒否しているサイトを教えてください。ホワイトリスト登録するよう私から言いましょう」と申し出た。
しかし、それっきり返事は来なかった。宛先サイトでもちゃんとホワイトリスト登録して、送達に困らなくなったんでしょ、きっと。
こういうこともあるので、ルール1は厳しすぎると思う人がいるであろう。実際、「3個以上の数字列」と条件を緩めて運用している人もいるようである。もちろん、人それぞれいろいろな工夫をしてくださってよい。
しかし私は、ルール1の条件の提案を変えるつもりはない。数あるメールサーバの中でルール1に引っかかるものは少ないが、「2個の数字列」という条件でスパムやウィルスメールが食い止められる頻度はかなり高いからである。
月曜日, 7月 24, 2006
Unknown hosts
S25R方式を発表して間もないころ、「逆引きできないホストに対する受信拒否は百害あって一利なしだ」という主張を引き合いにして「考え直したらどうだ」とメールで書いてきた人がいた。ホワイトリストの説明をちゃんと読んでくれていなかったようである。
逆引きできない正当なメールサーバがあることくらい先刻承知である。しかし、逆引きできないホストのうち、ほとんどはエンドユーザー回線でスパムやウィルスの発信源になっており、正当なメールサーバはごく一部である。そこで、S25R方式では、逆引き名から素性を推定できないという理由により、応答コード「450」で蹴ってみるのである。それに対する規則的なリトライが検出されたら、正当なメールサーバであろうと推定できる。そこで、ホワイトリストで救済するのである。
正当なメールを受信しないことは、受信者にとっても損失になる。逆引きできないという理由で、規則的なリトライを蹴りっぱなしにしたり、「5xx」を返してエラーリターンさせたりすることなど、どうしてできようか。
ついでに言えば、私は、メールサーバは逆引きを設定してくれた方がよいとは思っているが、逆引きできないメールサーバをいまいましいと思ったことはない。逆引きできないメールサーバからの正当なメールは、黙ってホワイトリストで救済している。それで、以後の受信には支障がなくなる。送信元のサイトに逆引き設定を要求したことなど一度もない。
ところで、hi-hoでは、逆引きできないホストからのメールを蹴るようにしたことがあるが、1ヶ月ほどでやめたそうである。正当なメールの救済策をとらなければ、ユーザーから苦情が殺到するのは当然である。スパムやウィルスを阻止するためなら、少しくらい正当なメールを巻き添えにしてエラーリターンさせてもしかたがないとでも思っていたのだろうか。グレイリスティングという救済策もあっただろうに。
逆引きできない正当なメールサーバがあることくらい先刻承知である。しかし、逆引きできないホストのうち、ほとんどはエンドユーザー回線でスパムやウィルスの発信源になっており、正当なメールサーバはごく一部である。そこで、S25R方式では、逆引き名から素性を推定できないという理由により、応答コード「450」で蹴ってみるのである。それに対する規則的なリトライが検出されたら、正当なメールサーバであろうと推定できる。そこで、ホワイトリストで救済するのである。
正当なメールを受信しないことは、受信者にとっても損失になる。逆引きできないという理由で、規則的なリトライを蹴りっぱなしにしたり、「5xx」を返してエラーリターンさせたりすることなど、どうしてできようか。
ついでに言えば、私は、メールサーバは逆引きを設定してくれた方がよいとは思っているが、逆引きできないメールサーバをいまいましいと思ったことはない。逆引きできないメールサーバからの正当なメールは、黙ってホワイトリストで救済している。それで、以後の受信には支障がなくなる。送信元のサイトに逆引き設定を要求したことなど一度もない。
ところで、hi-hoでは、逆引きできないホストからのメールを蹴るようにしたことがあるが、1ヶ月ほどでやめたそうである。正当なメールの救済策をとらなければ、ユーザーから苦情が殺到するのは当然である。スパムやウィルスを阻止するためなら、少しくらい正当なメールを巻き添えにしてエラーリターンさせてもしかたがないとでも思っていたのだろうか。グレイリスティングという救済策もあっただろうに。
日曜日, 7月 23, 2006
福音
S25R方式について私が最もメリットを強調したいことは、スパムの阻止率よりも、実装の容易さである。Postfixの設定だけで実現できるので、Postfixのオペレーションがどうにかできるというくらいのスキルレベルの人でも導入できる。このことは、中小企業には福音になるであろう。
中小企業では、自社のネットワークの運用のために高スキルのIT技術者を雇う余裕がないのが普通であろう。あるいは、高スキルのIT技術者は、稼ぐ仕事に回されて、自社のネットワークのめんどうをみる余裕がない。そのようなサイトでも、S25R方式は容易に導入できるのである。
問題となるのは、ホワイトリストの作成である。私の個人サイトではホワイトリストはごく小さくてすんでいるのだが、ユーザーが多いサイトでは登録数は500～1000件くらいになると聞いている。初めのうちは、ホワイトリストの作成に手間がかかるであろう。とはいえ、手間がかかるだけで、手順は簡単である。ログを見て、正当なメールサーバからと思われるリトライアクセスを見つけ出し、そのIPアドレスまたは逆引きFQDNを設定ファイルに書き加えて、Postfixをreloadするだけである。高スキルを要する仕事ではない。私の拒絶ログソーティングスクリプトを利用すれば、リトライアクセスを見つけ出す作業はいっそう容易になる。
導入者の方々からの報告によると、ホワイトリストは際限なく増え続けることはないようである。2週間から1ヶ月もたてば、ホワイトリスト登録の頻度は少なくなるとのことである。
1000人以上の規模のサイトになると、手動でホワイトリストを作るのは現実的でなくなるかもしれない。そのくらい大規模な組織では、佐藤さんのRgrey（S25R+postgrey）を導入するとよいだろう。必要なスキルレベルは、素のS25R方式よりも少しだけ高くなるが、大規模組織ならそのくらいのスキルを持つ人を確保するのは容易であろう。
中小企業では、自社のネットワークの運用のために高スキルのIT技術者を雇う余裕がないのが普通であろう。あるいは、高スキルのIT技術者は、稼ぐ仕事に回されて、自社のネットワークのめんどうをみる余裕がない。そのようなサイトでも、S25R方式は容易に導入できるのである。
問題となるのは、ホワイトリストの作成である。私の個人サイトではホワイトリストはごく小さくてすんでいるのだが、ユーザーが多いサイトでは登録数は500～1000件くらいになると聞いている。初めのうちは、ホワイトリストの作成に手間がかかるであろう。とはいえ、手間がかかるだけで、手順は簡単である。ログを見て、正当なメールサーバからと思われるリトライアクセスを見つけ出し、そのIPアドレスまたは逆引きFQDNを設定ファイルに書き加えて、Postfixをreloadするだけである。高スキルを要する仕事ではない。私の拒絶ログソーティングスクリプトを利用すれば、リトライアクセスを見つけ出す作業はいっそう容易になる。
導入者の方々からの報告によると、ホワイトリストは際限なく増え続けることはないようである。2週間から1ヶ月もたてば、ホワイトリスト登録の頻度は少なくなるとのことである。
1000人以上の規模のサイトになると、手動でホワイトリストを作るのは現実的でなくなるかもしれない。そのくらい大規模な組織では、佐藤さんのRgrey（S25R+postgrey）を導入するとよいだろう。必要なスキルレベルは、素のS25R方式よりも少しだけ高くなるが、大規模組織ならそのくらいのスキルを持つ人を確保するのは容易であろう。
「25」とは？
「Selective SMTP Rejection」を略して「S25R」。「25」とは何かというと、SMTPのポート番号である。私の論文の対象読者であるメールシステム管理者には当たり前の知識なので、なぜ略称で「SMTP」が「25」に置き換わっているのかなどという説明は書かなかった。
常識的な略し方なら「SSR」とでもなるところだろうが、元々略称である「SMTP」（Simple Mail Transfer Protocol）をさらに「S」と略すのは好きでなかった。だから、「SMTP」を短くするためにポート番号に置き換えたわけである。
スパム対策についての知識がある方ならピンとくるであろう。スパム対策の一つである「OP25B」（Outbound Port 25 Blocking）を意識したネーミングである。ご存じない方のために説明すると、OP25Bとは、ISPが自社網のダイナミックIPアドレスのエンドユーザー用回線から外へ宛先ポート番号25（つまりSMTP）のパケットが出るのを禁止するという策である。
常識的な略し方なら「SSR」とでもなるところだろうが、元々略称である「SMTP」（Simple Mail Transfer Protocol）をさらに「S」と略すのは好きでなかった。だから、「SMTP」を短くするためにポート番号に置き換えたわけである。
スパム対策についての知識がある方ならピンとくるであろう。スパム対策の一つである「OP25B」（Outbound Port 25 Blocking）を意識したネーミングである。ご存じない方のために説明すると、OP25Bとは、ISPが自社網のダイナミックIPアドレスのエンドユーザー用回線から外へ宛先ポート番号25（つまりSMTP）のパケットが出るのを禁止するという策である。
土曜日, 7月 22, 2006
広まりつつあるS25R
S25Rスパム対策方式を発表してから2年たった。今ではかなり広く注目されているらしい。批判もあるが、支持者の方が圧倒的に多そうなことが、検索から見てとれる。「予想以上の効果に驚いた」という証言がウェブページやBBSで見つかる。「導入者の皆様の声」への掲載を承諾してくださった方だけで現在11人。ほかに、メールやBBSで質問やホワイトリスト情報を寄せてくださった導入者の方々が数人いる。私には知らせてもらっていないが、導入していると公表しているサイトが見つかる。このことから推測すると、導入しているサイトは100を優に超えるのではないかと思う。うれしいことである。
S25R方式の広まりは、もちろん私だけによる成果ではない。qmailに実装した廣島さん、sendmailに適用可能にした伊藤さん、Postfixとqmailでグレイリスティングとの組み合わせを実現した佐藤さんらのボランティアのおかげである。大規模サイトでの導入について貴重な情報をくださった方々もいる。これらの方々に心から感謝したい。
このブログでは、S25R方式に関する雑多な情報をつれづれなるままに報告しようと思う。関心を持ってくださっている方々の参考になれば幸いである。
さて、いつまでネタが続くことやら…
S25R方式の広まりは、もちろん私だけによる成果ではない。qmailに実装した廣島さん、sendmailに適用可能にした伊藤さん、Postfixとqmailでグレイリスティングとの組み合わせを実現した佐藤さんらのボランティアのおかげである。大規模サイトでの導入について貴重な情報をくださった方々もいる。これらの方々に心から感謝したい。
このブログでは、S25R方式に関する雑多な情報をつれづれなるままに報告しようと思う。関心を持ってくださっている方々の参考になれば幸いである。
さて、いつまでネタが続くことやら…
登録:
投稿 (Atom)