メールというインターネットの闇
※この文書では メール＝e-mail です
メールというと哀れみの目線がエンジニアからとんでくる昨今
わたしのお仕事の半分以上はメール関連なのですが、ITなエンジニアの集まりで「メールのお仕事してます」というと
- うわ、レガシーな領域の人なんだ！
- メールってまだ仕事になるの？
- スパム屋さんかな？
と、マイナスというか哀れみな目線をいただくことがあります。
大きな本屋さんに行ってみると分かるのですが（例えば、丸の内オアゾの丸善さんとか）、メールの書き方など仕事でメールをどう活かすかみたいな本はありますが、システム的な見地の送受信に関する本は、ここ5年出版されていません。
たぶん、Postfix実践入門(2010/9/3発売)が一番新しい思います。
https://www.amazon.co.jp/Postfix%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80-Essential-Software-Guide-Book/dp/4774143758/
（あとは、CentOS7入門とかその手のLinux全体の本の中に、一章割かれる形で触れられていますね）
これだけ見ると、技術的には重要ではない領域に見えてしまいます。
メールは使われているの？
お正月のあけおめ！挨拶は、年賀状からメールになり、メールからLINEやTwitterになりました。そんな感じで日本国内のC2Cなコミュニケーションは、メッセージングアプリに移行し、B2BもSlackなどでやり取りすることが多くなりました。
このため、メールの量って減ってるんでしょう、と思われがちですが、増えてます。まず、世界全体で使用者数が年2～3%で増えています。
https://www.statista.com/statistics/255080/number-of-e-mail-users-worldwide/
日本国内でも（おそらく）増えています。日本国内だとユーザー（アカウント数）は増えていませんが、一人当たりに届く量が増えて、結果、流量が増えている感じです。どこで増えているかというと、B2Cの領域です。それと会社間のB2Bも減ることなく増えるところです。
闇要素もいっぱいだけど重要なメール
では、インターネットメールがないインターネットは果たして成り立つのか？と考えると、成り立たないと思っています。インターネット上の誰かが誰かに何かを伝えたいときに、インターネットの標準で定められたメッセージングプロトコルで流量が多いものはメール(SMTP)しかありません。
LINEもSlackもFacebook Messangerも一社に委ねられたクローズドな仕組みで、メールアドレスという記号が分かれば世界中の誰から誰かに届く、という便利さはありません（その反面、迷惑メールの問題がつきまとう）。
「メールアドレスという記号が分かれば世界中の誰から誰かに届く」というメールに特有な性質を利用して、インターネット上の多くの通知はメールでなされます。ECサイトでぽちっと購入したり会員登録したらメールが飛んできます。この手のシステムを担当していますが、障害があってメールが送信できなければ、
- ECサイトの会員が「メール届かないんだけど」とECサイトのコールセンターに電話する（たくさん来る）
- ECサイトのコールセンター担当がECサイトのシステム担当に連絡する
- ECサイトのシステム担当が私のようなメール担当に連絡する
と、速やかにエスカレーションされます……（私もいろいろやらかしたのでいろんな方角にごめんなさいできます）。
インターネットをうろうろしていると（特に一昔前は）メールがうざったい・迷惑だ、という声が多いのですが、昔も今もメール関連のエンジニアは、迷惑メールをいかに防ぐかということと同じくらい「メールが届かない。何とか届くようにして」という問い合わせにも日々対応しています。
ってなわけで「派手さはないけどこれ止まると影響大きいからね。メールは重要な役割だからね。」って声を大にしていいたいわけです。
闇の例：IPレピュテーション
そんなメールですが、書籍やサイトで取り上げられることが少ないので、使われているわりに最近の情報があまり出ていなかったりします。この辺りはいい感じで闇です。その中でも闇要素として、「IPレピュテーション」という概念を取り上げてみます。
私はメールを送る側と受け取る側に送る側の仕事が多いので、送る側視点で書いています。
IPレピュテーションとは？
メールのプロトコルSMTP(Simple Mail Transfer Protocol)は、バケツリレー式のプロトコルです。
例えば、ECサイトの注文完了メールが手元に届くには
| 通信 | 送信元 | 送信先 | 箇所 |
|---|---|---|---|
| 1 | ECサイト内のAPサーバー | ECサイト内のMTA(メールサーバー) | ECサイト内 |
| 2 | ECサイト内のMTA(メールサーバー) | 宛先ドメインのMTA(メールサーバー) | インターネット越し |
| 3 | 宛先ドメインのMTA(メールサーバー) | 宛先ドメインのメールボックスがあるサーバー | 宛先ドメイン内 |
| と、この例では3回の通信がなされます。1が終わったら 2、2が終わったら 3とバケツリレーされます。 | |||
| ※3の後に、メールボックスにあるメールをWebで見たりPOP3などでメーラーがメールを取得したりする |
このSMTPを使用したメールのバケツリレーの様相は、ブラウザとWebサーバーが End to End なHTTP(S)と大きく異なります（HTTPにもプロキシはあって通信が多段になることはありますが、バケツリレーではない）。
「IPレピュテーション」という概念は、上の表の2の通信、インターネット越しに送る側と受け取る側がSMTP通信するところに係わります。
レピュテーション=評価、です。メールにおけるIPレピュテーションとは、受け取る側の送る側の送信元IPアドレスに対する評価 です。この評価によって、受け取る側のメールサーバーは
- メールを速やかに受け取り受信者の受信箱に配送する
- メールを受け取るが、受信者の迷惑メールボックスに配送する
- メールをそもそも受け取ってくれない
など振る舞いを変えます。
また、IPレピュテーションは受け取る側がそれぞれに持つ指標なので、何かインターネットで一つの値があるわけではなく、1つのIPアドレスに対し受け取る組織の数だけ（＝無数に）あります。
SMTPはインターネットに対し公平ではない
メールのインターネット越し送信において、その送信元IPアドレスの「IPレピュテーション」は、高いほどベターで正常に受け取ってもらえます。低いと受け取ってくれなくなります。
この概念がある理由は、迷惑メール(正確には、フィッシングメールなど含めてunsolicited なメール)を防止するためです。迷惑メールを多量に送る送信元IPアドレスはIPレピュテーションが低くなるので、IPレピュテーションが低いところからのメールをなるべく受け取らないように、受け取り側のメールサーバーが振舞えば、受け取り側のメールサーバーでメールを受信する方に迷惑メールが届きにくくなります。
IPレピュテーションは、
- 今までどのようなメールを送信したか
- 近隣のIPアドレスのIPレピュテーション
によって（おおむね）決まります。
この「IPレピュテーション」の概念がある結果、エンジニア的には何か起きるかというと、適当にインターネットと面した新しいメールサーバーを同じ手順で構築しても、そのIPレピュテーションが違えば、立てた場所(IPアドレス)によって送った結果が異なる 、ということが起きます。具体的には同じ手順でCentOS7あたりを使って
1.AWSのEC2でメールサーバーたてた
2.さくらのクラウドでメールサーバーたてた
3.自社のオンプレミスなVM上にメールサーバーたてた
で、これらメールサーバーを使ったとき、正常届くか迷惑メールとして届くか届かないかは異なった結果になります(手順は同じなのに)。
HTTP(S)で同じ手順で同じプログラムをAWSとさくらのクラウドと自社のオンプレミスなVMにリリースして、手元からアクセスしたとき、あるところでは見えてもう片方で見えなかったら泣くと思うんです。でもそういうことがメール(SMTP)では平然と起きます。闇です。
重要な指標なのにIPレピュテーションが公開されないことで成り立つエコシステム
このメール送信上、重要な概念であるIPレピュテーション、受け取る側は公開しません。公開したら迷惑メールを送る悪い人たちも使用してしまうためです。では、どこかで迷惑メールを送信しないと認定された人たちの間でIPレピュテーションの情報がやり取りされているかというと、そんなやり取りもありません（GAFAのようなビッグプレイヤーは例外かも）。誰もが広く使用できる、というメールの概念上、送信する誰かを特別扱いするということはされません。
その結果、受け取る側と送る側が手探りというか暗中模索でIPレピュテーションに対して行動する中で、だいたい望ましいメールは届き、望ましくないメールはそこそこの量ですむ、というエコシステムが成立しています。
IPレピュテーションを知るための方法
受け取る側ではありませんが、受け取る側と情報を交換して、それをインターネットに出している奇特な会社さんがあります。私がよく参照するのは
- ReturnPath社のSenderScore ( https://www.senderscore.org/ )
- Cisco社のTalos( https://talosintelligence.com/ )
です。
ここで数字が低かったら(SenderScoreなら80未満)送り方に問題があるか、近くのIPに迷惑メールを送る悪い奴がいるかです。
例えばPayPalさんから来たメールの送信元IPアドレス「142.54.244.131」のIPレピュテーションを SenderScore で拾ってみると、
と100点満点中99点です。素晴らしい。
一方でいま（2019/12/14）たくさん迷惑メールを送っているIPアドレス「3.112.241.30」のIPレピュテーションを SenderScore で拾ってみると、
と100点満点中9点です。のび太のテストの点数みたいになっています。
ただ、日本国内の配信では、SenderScore、Talosで見るIPレピュテーションが低いことは迷惑メールの踏み台になっているケースで多いです（除く、迷惑メールを自ずから配信している場合）。まっとうな配信をしていて上２つの評価が高くても、ある受け取り先ではその受け取り先固有のIPレピュテーションが低いために、届かない場合がしばしば発生します。
このため、送信するメールの記録・ログを見て、届くかどうかの状況からIPレピュテーションを想像する場合が多いです。
送信するエンジニアができること
ここまで書いて力尽きたので後編(12/22公開予定)に続きます。すみません。