この記事は、メール Advent Calendar 2018 の13日目に書かれています。
参加者が意外に少なくてちょっと寂しい。
「キャリアブロック」というスラングがどの程度メジャーなのかはわからないんですが、少なくともメールサーバの運用をしている人で携帯キャリアのメールアドレスに送る状況が多い人や、あとメールマーケティング系の人の間ではそこそこ有名なキーワードなのかなと思います。もうちょっと一般的なスラングで言ってしまえば「受信サーバ側から一時的にBANされる」というのがそれなりに適切かもしれません。
一方でそのままキーワード検索をしてみると、メール配信サービスやマーケティング寄りの方が書いた解説が多く出てきて、必ずしも技術的な見地からは十分でなかったり正しくなかったりする印象があります。またシステム運用側の立場から見ても、よほど携帯電話などにメールを多く送るというシチュエーションがないと遭遇しないこともあり、加えて携帯キャリアやその他のメールサービスもその仕様を明らかにはしていないので、その実態はあまり明らかではないのかもしれません。
そんなわけで「キャリアブロック」とはそもそもどういったものなのかを考察してみたいと思います。自己紹介がてら立場を明らかにしておくと、私はどちらかというと「送る側」の人間です。メールを受信するサーバの運用もしていますが、某メール配信サービスのサーバの管理をしていたこともあり、携帯キャリアやプロバイダ宛に数万単位のメールを送るとどういう挙動をするのかはだいたい把握しているつもり。ただあくまで「送る側から見た印象」であることをご承知おきください。
そもそも「キャリアブロック」って
主に携帯電話のキャリアメール（@docomo.ne.jp・@ezweb.ne.jp、@softbank.jpなど）が発動する「受信制限」のことを総称して「キャリアブロック」と呼んでいます。具体的にはあるキャリア宛のメールを送った時に「行儀の悪い送り方」と判断されると発動して、そのIPアドレスからのメール送信（SMTP接続）を受け付けてくれなくなります。歴史的経緯から2000年代前半頃に携帯キャリアのメールにおいてこの制限がキツかったため「キャリアブロック」という呼び方をしますが、似たような制限はプロバイダ（OCNとかNiftyとか）やメールサービス（YahooメールとかGmailとかOutlook.comとか、いわゆる「メールボックスプロバイダ」）でも存在します。そして当たり前ですが、企業のメールとしてG SuiteやOffice365を使っている場合も、同様の制限に遭遇することがあります。また後述もしますが、Postfixでも似たような制限を行うことが可能ですので、オンプレ環境なメールサーバでも制限されることはあります。そういう意味では「受信制限」という言い方の方が汎用性が高いのかもしれません。
何故「キャリアブロック」が存在するのか
メールを受信するサーバを運用している人ならわかりますが、大量のメールを送信された場合サーバの負荷が上がりリソースを食い尽くします。具体的にはMTAのプロセスが大量に起動したりしてメモリを食ったり、メールを受信して（ローカル配送でも転送でも）キューイングするのにディスクI/Oが上がったりということが起こりえます。これを防ぐためにとりあえず行儀の悪いIPアドレスからの接続をネットワークレベルでブロックしようという理由は理解できます。
またこのような行儀の悪い送り方をしてくるのはスパマーである蓋然性が高いという考え方もあるのではないかと思います。いわば「遅発性グレイリスト」的な運用の仕方ですね。
さらに携帯電話キャリア固有の理由として、大量のメールを受信してしまうとユーザの端末にプッシュ通知をしなければならず、基地局側の輻輳を招きかねないという理由も考えられます。今の4G時代・スマホ時代だと以前に比べると問題は起きにくいのかもしれませんが、2Gや3Gの初期の時代に特に地域性の高いメールを送ると特定の基地局に負担がかかるという事象は想像できます。実際に某チェーン展開をしてる企業が特定の店舗で会員登録したユーザ向けに一斉にメールを送ったら、特定の市町村でメールトラフィックが増えたという噂は聞いたことがあります。
どういう条件で「キャリアブロック」が発動するのか
「行儀の悪い送り方」と書きましたが、そのディテールは各社の企業秘密です。
実際に受信制限を喰らったサーバの送信ログなどを眺めていると、量的制限と質的制限のどちらかか両方があるのではないかと思われます。
量的制限とは単位時間当たりで同一IPアドレスから一定数以上の送信（あるいはSMTP接続）があると発動して、それ以降は新規の接続を受け付けないという動作をします。Postfixで言うところのsmtpd_client_connection_rate_limitによる制限に近い挙動と理解しておけばよいと思います。
質的制限とはエラーのアドレス宛の送信が多いと発動するという動作です。やはり同じように単位時間当たりの宛先アドレスに一定数以上のエラー（SMTP的には550 User Unknownなど）のメールを送ってくるIPアドレスに対して、以降は新規の接続を受け付けなくなります。単位時間当たりの絶対数で評価しているのか、総接続数に対するエラーの割合で評価しているのかはなんとも言えないところです。こちらはPostfixで言うところのsmtpd_hard_error_limitに近い制限と思われます。
また当たり前ですが、単位時間やそれぞれの閾値がどの程度なのかというのが企業秘密なわけです。企業秘密ではあるものの、概ねこのような制限があるメールサービスは多いです。サービスによりますがどちらか（特に量的制限）のみで運用しているところもありますし、両方で運用しているように見えるところもあります。特に3大携帯キャリアは量・質両方で制限を行っていると思われ、一般のプロバイダやメールサービスに比べてその閾値が厳し目ではないかと感じます。だからこそ「キャリアブロック」と呼ばれるわけです。ただ数分の間に3桁から4桁の規模以上でメールを送ったりエラーがあったりしないと発動しないようには感じますので、ごく普通のメールサーバであれば遭遇する機会はあまりないと思われます。
発動するとどのような挙動になるのか
「受信制限」が発動された時の挙動もやはり各社によってまちまちではありますが、多くの場合SMTP接続自体が拒否されます。細かくパケットをキャプチャして確認したわけではありませんが、接続をしようとした瞬間すぐに切断されることが多いので、最初の25番ポート宛のSYNに対してSYN ACKではなくRSTパケットが返されることによって接続が拒否されるという具合で、TCPレベルで拒否されているように見えます。
送信側が真っ当なMTAの場合、これは421の一時的なエラーとして処理され、MTAの設定に従ったインターバルで再送を試みます。しかしキャリアブロックを喰らって滞留したキューが大量にあるとまた接続数が多くなったりして同じようにSMTP接続が拒否されて、最終的にキュー生存時間までにまでに送りきれないという事態になりがちです。さらに「ブロックしてるのにそれでもしつこく送ってくるホスト」と判断されると、制限がさらに長引きます。
どうすれば解除されるのか、喰らわないのか
一度、受信制限を喰らってしまった場合、どのような条件で解除されるかもまた各社によってまちまちです。数十分で解除される場合もありますし、数時間や下手をすると24時間以上同一IPアドレスからの接続が拒否され続けるということもあります。基本的にはそのIPアドレスからブロックされている宛先に対してのメールを送らないようにしてしばらく「寝かせる」しか解除される方法はありません。
そもそも受信制限を喰らわなければいいんですが、どうすればいいのかと言えば「行儀良くメールを送る」こと以外にできることはありません。具体的には
- 同一ドメイン宛に大量・高速でメールを送らない
- エラーになるアドレス（存在しないなど）にメールを送らない
という点に尽きます。前者は送信側のMTAである程度チューニング可能です。Postfixならsmtp_destination_concurrency_limitなんかで設定するところです。後者はメルマガ配信などの運用に属するところでもありますが、エラーとなったアドレスに対する管理をちゃんと行って、エラー率を低く抑える運用を行いましょう。
自社でメールサーバを運用してる企業なんかだと、マーケティング担当者だったり開発担当者だったりがやらかして制限を喰らって、他の業務にも影響が出たりして情シス部門と揉める姿が想像できてしまいます。くわばらくわばら。
メール配信系のサービスとかってどうしてるのかって？
それでも「携帯電話に超スピードでメール送りたいんだよ」というマーケティング担当者はいらっしゃるでしょう。素直にメール配信系のサービスの利用を考えてください。それなりに高速に送るためのノウハウだったり、エラーになったメールを少なくとも次回配信時にどうするのかなどのノウハウや仕掛けがあります。
逆にメール配信系のサービスを運用してる側からすると、「行儀の悪いユーザ」がいると携帯キャリアに限らず受信側のメールサービスから制限を喰らったりして、日々この制限との戦いだったりしますので、お察しください。
一方でSendGridやSESなんかだと「IPアドレスウォームアップ」の必要性が説かれますが、個人的にはちょっと懐疑的です。理屈はわかるけど、そういうレピュテーション情報を受信サーバがどこまで参考にしてるかっていうのはわからないからです。RBLなんかに載ってるIPアドレスをブロックするのはまだ動機があるけど、「ウォームアップされて何か良さげなIPアドレス」を優先的に受信してやる動機も別に無いからですね。他のユーザの影響を受けないという意味では専用のサーバや専用のIPアドレスの意義は大きいんですが、配信状況のモニタリングやエラーになったアドレスに対する処置などは継続的に運用していかなければならないわけです。確かに「送り慣れてきたIPアドレス」からだと大量に速く送っても意外と平気という状況があるような気はしますが、気がするだけかもしれません。どちらにせよ受信するサーバ側のさじ加減次第なんで、日頃からエラーが少なくお行儀よく送る心がけのある運用をすればいいだけだと思います。
そんな努力をするくらいならDKIMやDMARCがもっと普及すればいいのにとは思いますが、IPアドレスだけの判断だとネットワークレイヤーのみで対処できるから手軽なんだろうなとも感じられるので、しょうがないのかもしれません。
メールを大量に送りたい人が忘れてはならないこと
意外と基本的すぎて忘れられがちですが、メールは送信サーバと受信サーバが存在するから成り立ちます。「メールを速く大量に送りたい」というニーズがなくなることはそうそうないとは思いますが、送る側だけでなく受け取る側も多大な努力をしています。得てしてスパムとの戦いになってしまっているのが悲しいところではありますが、スパムや行儀の悪いメールをブロックしつつも、そうではないメールは全力で受け取りたいというのがメールサーバ管理者の本懐です。
そして送る側も極力可能な範囲で全力でメールを送りたいので、ユーザの皆様に置かれましては行儀の良い運用を心に留めておいて欲しいなと思います。