Supamhausに代表されるいわゆる【RBL】と言われる、ブラックリスト。
最近は大手もRBLを利用したスパムチェックを使う業者も増えてきました。
RBLは、利用する側の立場としては、ブラックリストを自動的に更新してくれる利便性もあり、確かに楽にSPAMメールを減らすことができますが、その反面、本来ホワイトであったはずのメールまでもが届かなくなるケースも多いのです。
RBLの簡単な仕組み
ヘッドライン
RBLは、仕組みとしてはシンプルで、SPAMを送っているメールサーバーだと認識した場合に、【IPアドレス】を、ブラックリストに入れる仕組みです。
送信元のIPアドレスがブラックリストに入っていた場合、要はこのメールはブラックリスト入りしているIPから送られているよとメールにフラグを付けます。
そして、ほとんどの場合、サイレント（受け取る側にも送った側にも通知をせずに）に削除します。
RBLがIPアドレスでブラックリストに入れる理由
これは、実はシンプルな理由です。
ドメイン型のブラックリストの場合、本来はホワイトなドメインだが、スパムを送る側が、ドメインを偽装してメールを送信しているのにもかかわらずドメインをリスト入りさせてしまうことになるからです。
例えば、Amazonを騙ったスパムメールがあったとします。スパマーは、メールアドレスを、Amazon.comや、Amazon.co.jpと偽装して送っていることが多いので、ドメインでブラックリストに入れるとしたら、Amazonの公式のドメインを入れることになります。
これをやってしまうと、本来の正しいAmazonのメールも受け取れなくなりますよね。
これでは、ブラックリストの意味がありません。
なので、IPアドレスで、ブラックリストを作ります。
IPアドレスはユニークなもの（簡単に言えば、そのIPアドレスは、世の中に1つしかない。イコール、使用者が固有で限られている可能性が高い。だから、そのIPからのメールを受け取れなくすればほかのドメインを偽装してきても、IPでブロックできる）なので、ブラックリストにするにはふさわしいユニークなものになります。
しかし、弊害もあります。
例えば共用型のホスティングサービスを利用していて、同じ収容サーバー内の自分ではない誰かがSPAM配信をやり、そのうえでブラックリスト入りした場合、同じIPを使っている自分のドメインからのメールも送れなくなります。これは困りました。これについては防ぎようがないのが現状です。
なので、RBL業者は解除申請というのを設けており、リスト入りした原因を究明して、対応をしてくれるのであればブラックリスト入りしたものを消してくれます。
もちろん、その後またリスト入りする条件にはまればリストインしますし、繰り返すようだと、その後解除はしてもらえなくなることもあります。ここらあたりは、サーバー業者の仕事ですが。
ブラックリストはブロック単位
さて、上記のような要件があるため、IPアドレスでブラックリストを作っていると説明しましたが、実はほとんどのRBLは、IP単体ではなく、ブロック単位というグループ単位でリストを作ります。
これはどういうことかと言うと、IPアドレスというのはいくつかの数でまとまってブロックという単位でネットワーク網を構成しています。
Windowsユーザーならネットワーク設定内の【サブネットマスク】と言われるものがブロックを管理するアドレスになります。
いまや、ネットワークは家庭内でも、マシンが1台とは限らず、スマホやタブレットもWi-Fiを使って家庭内のネットワークLANに接続するのが一般的ですから、各端末にはローカルIPと言われるネットワークアドレスを割り振ります。
その際、Windowsの既定の設定のサブネットマスクには255.255.255.0と記載されているのを見たことがあると思います。
ipv4のネットワークであれば、ネットワークアドレスは0.0.0.0~255.255.255.255までとなり、サブネットマスクでは0がフリー（最大255までつかえる）で、255が使えない（その部分はいじってはダメ）という表記になります。
255.255.255.0というサブネットマスクなら、ローカルIPでいえば、192.168.1.0～192.168.1.255までの256個は使えますよ（あくまで一例）と言う表記です。
IPアドレスというのはこのようにIPアドレス網にグループを作っており、使える数の幅を示すものがネットマスク（ビットマスク）といいます。
小さい単位だと、IPが8個だけ使る29ビットマスク（255.255.255.247）なんかもあります。
これは、上位IP管理者が下位プロバイダなどにIPの利用権限を付与するときに、ここからここまでと範囲を決めて割り振るときにビットマスクを決めて割り振ります。
一般的には（習慣的には）そのブロックの一番頭のIPをルーターにつけるIP、最後のIPアドレスをブロードキャストIPとするため、ブロックを切ると、前後2つのIPは使えなくなると思っても間違いではありません。
そういうことがあまり関係がない小さなホスティング業者の場合、16~64個程度の割り振り幅の歯抜けのIPブロックなら容易にもらえるのでそういう歯抜けのIPブロックを上位プロバイダから割り振ってもらい、利用していることが多いのですが、GMOやさくらクラスの大きな業者になると、管理しきれなくなることと、分ければ分けた数×2IPが使えなくなるので、16000個程度使える18ビットマスク程度の単位で割り当ててもらい、そのまま使うことが多いのです。特段の事情がない限り、割ることはあまりないですし、128IP以上のIPを、下位から要望された場合はこのような大手業者は自社のIPではなく、新規で申請して持ってくることも多いのです。
さて、話は戻りますが、RBLというのはこのブロック単位でブラックリストに入れていく仕組みのものが多いのです。
前回、GMOがspamhausのRBLにブロックが登録されて大惨事になっている記事を書きましたが、これは、ブロック単位でリストインさせる仕組みのspamhausに、GMOが保有する18ビットマスクのIPブロック網が入れられてしまったことが原因でこの大惨事が起きました。18ビットマスクというのは裏を返せば、14ビット使えるIPです。16384個―2個＝16382個自由につかるIPブロックです。今回のIPブロックはGMOでは主に、VPSやALTUSなどのクラウド仮想サーバー系で使っていたブロックのようです。
これは、上記のように、大手業者は細かいブロックにすると管理が大変なので大きなブロック単位で管理していたことが原因でこうなってしまいました。
小分けにすればつかるIPの数は減るし、管理が分けた分だけ煩雑になりますから、できればそのまま使いたいというのが心情でしょう。GMOからのコメントではどうやらとある1契約者のVPSがSPAMの踏み台になったことが原因でガッツリやられたようです。仮想サーバーあたりを利用する方はある程度のスキルがあるという判断もあったのでしょうが、最近は全くLinuxがわからない方も、コスパの観点から仮想サーバーを利用しているケースも多く、本人が気づかないうちに踏み台になっちゃうことも多々あるようです。
そもそも、なぜRBLはブロック単位でリストインさせるのか?
これは管理していくうえでの特性からそうしているのだろうと推測していますが、SPAMメールを流しているクラッカーがいたとして、SPAMを送っているとします。
仮にRBLがIPを単体でリストインさせる仕組みだったとした場合、今SPAMを送っているサーバーのIPをブラックリスト入りさせてブロックすることなります。
では、そのSPAMクラッカーは次の行動として容易に推測できるのは、リストインしていないIPアドレスでメールを送ることです。サーバーをハッキングして踏み台にしていたのであればそれに近いサーバーに次はアタックするでしょう。
もし、自分で構築したサーバーであれば、今送っているサーバーのIPを付け替えればRBLデータベース的にはまたホワイトなサーバーと認識するのです。
IPの付け替えと言っても、ローカルIPの話ではなく、グローバルIP(インターネット上でユニークなIPアドレス)ですから、容易にまったく違うブロックのIPを取得できるものでもありません。
もし、SPAMクラッカーが新しいIPを準備できたとしても、今あるIPの近所のIP（1つ違いのIPアドレスだったり。）になる可能性が高いはずなのです。（同じ業者のサーバーであったり、その業者からブロック単位で割り当てられているIPであったりすることが多いはず）なので、RBL運営者的には、ブロック単位でリストインさせることでSPAMクラッカーの行動を先んじてブロックする行為でもあるのです。
理にはかなっていますが、WEB系のサーバーのほとんど、一部上場クラスの企業でさえ、業者が準備するレンタルサーバーを利用するケースが多い日本では、ブロック単位のリストインは結構致命的だったりします。かといって、IP単体だと、SPAMの排除が難しいので、消極的賛成という感じで利用してしまう感じになります。
今回のGMOのトラブルはその最たるものになりました。
いかに自社のメールサーバーをホワイトで守り続けるのか
今の時代、RBLはそれ以上に素晴らしいスパムチェックエンジンが開発されているわけでもないため主流と言っても過言ではないSPAMチェックエンジンです。
なので、ブラックリスト入りしてしまうかもしれないことを前提に、いかに、リストインした時に時間をかけずにホワイトにしていくか、GMOなど、提供会社の対策まちでは遅いのです。
ホワイトを守り続けるのであれば、自前でIPブロックを準備し、そのIPブロックは門外不出のIPブロックとして自前だけで利用し、第三者が使う余地を残さず、ホワイトに使い続けるしか方法はないでしょう。それでもリストインすることもありますが（悪意のある誰かがブラックリスト申請することもあるため。）
RBLの特性を理解できれば解決方法はある
RBLは、IPをブロック単位でブラックリストに入れる仕組みである。
というのを上記で説明してきました。
では、ブラックリストに入ったものをホワイトにする方法は、2つです。
1つは、解除申請を出して、解除してもらう方法、もう一つはホワイトなIPに付け替えてしまう方法の2つです。
※上記の条件2つともですが、自前のサーバーがSPAMの踏み台、温床になっているわけではないというのが前提です。
解除申請は通ればいいが通らいないことも多いし、RBLはたくさんある
解除申請を出して通ればまたホワイト認識になるので大丈夫ですが、自分が踏み台になっていないのであれば、自分の隣のIPを使っている誰かが原因で入った可能性もあり、自分たちだけが申請を出しても、解決してないからダメと、言われることも無きにしも非ずです。そしてRBLは1つではなくたくさんあります。数十という数のRBLがありますのですべて解除申請を出していかなければいけません。
なので、もちろんやれる限りのことは自分でもやるべきだと思いますが、提供している業者がやるべき仕事だと私は思います。
実際私がホスティングサービスを提供していたときはリストインするようなことがあれば、こちらで原因を調べ、原因になっているお客さんを特定し、SPAM配信を止めさせ（ほとんどの場合当人が悪意を持ってやっているのではなく、ウィルスに感染したりハッキングされて誰か別のものがSPAMの踏み台にしているのでメールアカウントを消したりパスワードを変更するとすぐに治るケースが多い）、そのうえで解除申請を出すということをやっていました。
これは、1契約者だけでできることではありませんからね。
ホワイトなIPに付け替えるのは簡単か？
Linuxのシステム上、IPを付けたり消したりするのは簡単です。しかし、共用のレンタルサーバーや、VPSサービスのようなものを利用している場合、IPを変えることは不可能です。
ほぼ100％無理でしょう。ホスティング業者に個別に依頼してもその業者がOKを出すはずもありません。
なぜなら、ipv4と言われる従来のIPアドレスは枯渇気味（と、言われているが、それは業者が独占しているからであって、実はそれほど枯渇もしていないらしい）と言われている昨今に、RBLのブラックリスト入りしたからIPを変えてくれという依頼に一つ一つ答えていると、IPがどれだけあっても足りないし、その依頼を受けてしまうと、業者は大変なことになるからです。
IPを簡単に取得、付け替えできるとすればAWS！
今回、GMOのトラブルに際し、解決方法の一つしてホワイトなIPで構築したメールサーバーを利用してリレーサーバーを作り、特定のメールについてはリレーサーバーを経由するように設定することでRBLのリストに入っているIP以外から送信するという逃げ道がGMOから提示されました。
しかし、リレーサーバー自身がブラックリストに入ってしまうようではお話になりません。
GMOが用意したリレーサーバーのIPを調べても、普段表に出していないであろう、見たこともないIPブロックを利用したようで、まっさらなものを使ったようでした。
（もちろんリレーサーバーを提供しても、その後リレーサーバーを使って誰かがSPAMメールを送るとブラックリストに入るから、今はGMOも細かくチェックしているようです。）
まっさらホワイトとは言わずとも、IPは今までと違うブロックでかつ、何かあったらIPブロックの違うモノを付け替えできたら自分たちでもリレーサーバーの構築は不可能ではないのではないか?などと思いました。
そして、たどり着いたのはAWSです。
AWSのIPは、何度かサーバーを構築してみましたが毎回ブロックも違うIPがつきますし、また、IPを追加で一つのサーバーに付け足すこともできました。
ようは、もし、RBLにリストインしてしまったらIPを追加して付け替えて古いIPを削除してしまうなんてことも不可能ではありませんでした。
日本語化されたインタフェースで、昔より容易に！
私はずっと苦手意識があって、その理由は、一つはコントロールパネルが当時（と言っても、サービスが始まった直後くらいの話）は英語しかなく、何がどこにあるのかもわからなくて、サーバー構築すらいけませんでした。
しかし今は日本語化されているので構築は容易です。
もう一つ苦手だったのはSSHログインを行うためにはAWSでキーペアを作らなければいけないという仕様になっており、そのペアを利用しないとSSHログインできませんでした。
それが本当に苦手意識に繋がっていたのですが、実際やってみてSSHをつないだ後は普通のLinuxなので、sshd_configあたりを自分の使いやすいように編集しちゃえば、AWSのキー以外の自前で作ったキーでもログインできるアカウントを作ることもできました。
この2つが今（2019年5月）なら、簡単にできたので、AWSで構築したサーバーもお勧めできるなと思いこの記事を書いています。
リレーサーバーの構築なら最小構成、無料枠の範囲で構築したサーバーで十分
私はRedHat系のサーバーが今までずっと使ってきていたディストリビューションなので、CentOSで、月額無料で使るt2.microで構築、Postfixあたりをyumでインストールしてメールサーバーを構築。必要なアカウントを作りリレーサーバーとして作ることができました。
これにより、リレーサーバーは、GMOからの提供を受けなくても、なんとななる。もっと言えば、さくらのVPSで同様のトラブルが起きてもリレーサーバーは何とかなるということがわかりました。
AWSなら、IPを新たに取得して従来サーバーにつけることが可能ですのでもし、リレーサーバーのIPブロックが何かの拍子にブラックリスト入りするようなことがあれば最悪退避方法として新たなIPを付け替えてしまうことで退避できます。（もちろん自分のサーバーが踏み台になっていない、誰か違う人が原因でリストインしたという場合）
GMOのVPSからAWSへの切り替えは検討できるのか?
リレーサーバーの構築もさることながら、AWSで作ったマシンをメイン稼働マシンにすることも可能です。
リソースの増減はインスタンスパッケージの変更でCPUやメモリ、トラフィック量などを変更できますし、HDDは、起動状態のまま増設可能です。
最小構成のサーバーからスタートしてコンテンツやトラフィック量に合わせてリソース構成を変更させることもできますし、費用については、GMOのVPSサービスとほぼ同等程度で運用は可能そうです。
Pleskのライセンスについても、Plesk本社（米国、英語でのやり取りのみらしい）でライセンスを購入するのであれば為替変動をあまり考えなければGMOのPleskライセンスとほぼ同じくらいの価格で調達可能です。また、AWSなら、PleskライセンスをAWSマーケットプレイスで購入することも可能です。（少しだけ割高だが、LanguagePackや、WPの管理ツールなども標準装備らしい）
なので、もう少し理解が深まればGMOからAWSの切り替えも検討できるかなと思っています。
