別記事でメール配送の仕組みを通じ、動作原理を理解することの重要性をお伝えしました。
今回はメールの仕組みについて、もう少し細かいところを話してみようと思います。
元々はシンプルなつくりだったメール配送システムが、現在はややこしいものになっている感があります。
それを歴史的背景から紐解く事で、何が問題なのか、どういったアプローチをとったのか、というところを知る事でインターネット技術に少しでも興味をもってもらえたらと思い、記事にしてみました。
単なる説明も多いので眠くなったらゴメンナサイ、ですが。
エンジニアの方にはぜひご覧いただきたいです。
メール配送の全体像
別記事で書いた内容を、さらに機能ごとに分解して描いた図がこちらです。
緑枠のアルファベット３文字は、メールの機能を一般的にこう呼んでいる、というところで書きましたが、正直ここまで詳しく覚えてもらう必要はありません。
逆に、省略前の英単語は覚えてもらった方が理解は進むと思います。
それでは、個別に説明をしていきます。
MUA(Mail User Agent) ‥ メーラー
左上の送信者が使うメーラーです。OutlookやGmail などのアプリを指します。
User Agent と聞くとWebブラウザーが送るものと理解しがちですが、ITで言う User Agent は利用者を示すプログラムを意味します。この場合は Mail User Agent なのでメールを扱う利用者向けプログラム、と理解すると覚えやすいでしょう。
さて、一般的に言うメーラーですが。これも分解していくといくつかの機能に分けられます。
ここでは「メールを送る」機能だとイメージしてください。
メーラーがメールを送る時は、当たり前ではありますが相手が分からないといけません。
その相手というのは、次に説明するMSA（送信サーバー）です。具体的には
- 送信先メールサーバー名（ホスト名）
- ポート番号
- ログインＩＤ
- ログインパスワード
このような情報です。
みなさん、メーラーをセットアップした事があれば思い当たるフシがあると思います。
MSA(Message Submission Agent) ‥送信受付と認証
MUA(メーラー)から送られてきたメッセージを受け付けるのが、MSAです。
submission という単語には「投稿、提出、提案」という意味が込められており、投稿されたものを受け付けるという事でsubmission agent という名前が付けられました。
ただ受け付けるだけではなく、ログインIDとパスワードでアクセス認証も行っています。
sendmail,postfix といった実装の一部分でもあり、歴史的経緯から言うと比較的最近実装された部分です。
OP25B（Outbound Port 25 Blocking）
MSAの前に「OP25B」と書いていますが、ここについて先に説明しましょう。
OP25B（Outbound Port 25 Blocking）とは、プロバイダー側でプロバイダー外に行くTCP/25(SMTPプロトコル)の通信をブロックします、という意味で、メールの仕組み、特に歴史的背景から生まれた後付けの仕組みです。
Outbound というのは「外向けの」という意味ですが、ここではISPより外への通信を指します。
Port 25 というのはTCP/25 という SMTPプロトコル（メール送信に関する通信手順）のこと。
ISP契約者が勝手に外に悪さをしないようTCP/25（SMTPプロトコル）をブロックしますよ、という意味です。
SMTPプロトコルは MTA同士でメールを転送するための通信手順として今も使われていますが、かつてはMUA（メーラー）はMTA（後述） に直接メールを送る事もできました。
SMTPプロトコルそのものには認証の仕組みはありません。誰でもメールを送る事ができます。
どういうことかというと、赤の他人が用意したSMTPサーバーを使う事が出来るという事です。
しかもFromアドレスを詐称できてしまいます。
転送をする、という処理を考えた時に、Fromという「誰が」という情報は不要だからです。
送り主が誰か、という事を気にする必要がなく、いくらでもメールを送る事が出来るわけですから、これを利用しない手はありません。スパムメールや詐欺メールが横行するのも自然な成り行きです。
とはいえ、メールの仕組みが出来た時はそんな事は起きていませんでした。～1990年までの話ですが。
元々インターネットというのは一部の技術者や研究機関など限られた人たちが使うもので、またインターネットが多くの人の援助のもと成り立っている相互扶助の通信環境でしたから、お互い信頼関係のもと節度をわきまえて使われていたものです。
それが一般人にも開放され、Windows95の登場で誰でもインターネットを使える時代になると（1995年～）、ずる賢い人も出てくるわけで、そういう人たちがスパムメールや詐欺メールを大量に発行し始めたのです。
さあこれは困った‥という事でOP25Bで身内（ISP利用者）が悪さをしないよう、外向けのTCP/25送信をブロックしよう！という話になりました。
でもそれじゃあ自分が契約しているISPのメールサーバーに、ISP外からアクセスできなくて困ります！そういう声がでますから、別の入口を作りましょう、となりPORT番号587をSMTPの新たな入口にしました。もちろん認証がないと元の木阿弥ですので、認証機能も入れた送信専用のプロトコルとしてサブミッションポートを使ったプロトコルが生まれました。
それ受け付ける仕組みがMSAで、sendmail や postfix といったアプリケーションの一部として実装されています。
2007年あたりから普及した仕組みです。
こうして認証を通過したメールだけが、いよいよメールシステムの核であるMTAに引き渡されるのです。
MTA(Mail Transfer Agent) ‥転送
メールを送る本体部分、いわば核となる部分で、これを知る事がメールの基本機能を知る事と言っても過言でないでしょう。
MUA（メーラー）から送られたメールのうちMSA（認証）を通過したものが、ここMTAに送られます。
または③のように、MTAから別のMTAを通じて送られる場合もあります。
OP25Bで説明したとおり、TCP/25（SMTPプロトコル）で通信されますが、認証機能に問題がある‥というか認証機能が無いため、Toアドレスが自身のものだけを受け取り、それ以外はreject(拒否する)ようにするなど設定されています。この設定を忘れてしまうと、スパムメールの発信元として知らず知らずのうちに踏み台にされている可能性がありますので、サーバー設定時は十分お気を付けください。
もうちょっとだけ補足すると。
ウェブサーバーを立ち上げる時にLinuxサーバーのセットアップをする人、又はAWSなどクラウドでサーバーを立ち上げて管理する人は少なくないと思います。大抵のLinuxにはMTA（sendmail等）が標準でインストールされます。MTAはTCP/25（SMTP）でリスニングしますから、外部からのメールを転送しないのであれば、Firewall等パケットフィルタリングでInboundのTCP/25を通さないようにするとか、もしくは 上で述べた通り To アドレスが自身のドメイン以外を拒否するといった設定をする必要があります。
ただ、最近の標準設定では上記２点は既に行われた状態で提供されるようなので、この事を知らない人もいるかと思いますが、下手にMTAの設定を触って踏み台にされないよう、最低限の知識として知っておいて下さい。
話を戻しますが。
MTAのコアとなる働きはこうです。
１．送られてきたメールのTo（送り先メールアドレス）をみて、自身が受けとるメールかどうかを判断する
２．自身が受け取るものであれば、続くMDAにデータを渡す（③ローカル配送と呼ばれる処理です）
３．自身が受け取るもの以外（外部のメール）であれば、DNSを参照して転送先を調べ、送信ドメイン認証機能があれば行い、別のMTAにメールを転送をする
これがメールが全世界に配送できる基本的な仕組みです。これがメールはバケツリレー方式と呼ばれる所以です。
もっとも、DNSによる名前解決が一般的になってからは、外部ドメイン間のメールは直接やりとりされるようになりましたから、バケツリレー方式ではなくなっています。
ただ、同一ドメインでアカウントが大量にありすぎてメールサーバーを分散させていたり、ウィルスチェックなど各種フィルタリングを行っているような環境で機能別にメールサーバーを構築している、などされている場合は、相変わらず次の転送先はどこ、というようにバケツリレー方式でメールを送るようになっています。
さて、３．の転送についてもうちょっと見ていきましょう。
OP25Bで少し話しましたが、SMTPプロトコルではFromアドレスは仕組み上使いません。MSAで認証が通ったとしても、相変わらずFromアドレス（送信元）は未チェックのため、いくらでも送信元を詐称できてしまいます。
この問題を解決するために、送信ドメイン認証、という仕組みが組み込まれるようになりました。
その一つがSPFという方法です。
SPF (Sender Policy Framework)による送信ドメイン認証
送信ドメイン認証というのは、送信ドメインが本人かどうかをチェックするための仕組みです。
SPFはその一つで、「Fromアドレス（ドメイン）は〇〇というメールサーバーから送られます」という情報を用いて認証を行います。
〇〇というメールサーバーに当MTAが含まれていれば認証する、そうでなければ認証しない、というマークを転送するメールに付与する仕組みです。
マークというのは、ヘッダーの事で具体的にはこのようなものです
spf=pass (google.com: domain of ●●●@en-pc.jp designates AAA.BBB.CCC.DD as permitted sender)ここで pass が記載されていれば、送信ドメイン認証されたという事。
他には 「none, neutral, fail(hard fail), soft fail, temperror, and permerror Explained」といったステータスもありますが、基本的には pass 以外は問題あり、と思ってください。
このチェックを行うために必要となる情報は、DNSサーバーのTXTレコードに格納されています。
例えばですが、このようなものです。
XXX.com. IN TXT ” v=spf1 +ip4:aaa.bbb.ccc.ddd –all”中身の説明はここではしませんが。
ポイントは、DNSサーバーの情報を変更できるのは、そのドメインの所有者だけだという事。
だから、チェックを行うための情報が正しいと保証されるのです。
他にも、DKIM、DMARCといった送信ドメイン認証もあります。
こちらも話が長くなるのでここでは割愛しますが、このような送信ドメイン認証というのは、ここMTAで外部に転送する際に行われます。
※ここポイント
MDA（Mail Delivery Agent） ‥ローカル配送
MTAの働きとしてもう１つ重要なのは、自身が受け取るメールを自身のサーバーに保存する事です。
自身が受け取るメールというのは、Toアドレスに含まれるドメイン（@より後ろの部分）が、MTA自身のドメインと一致するメールです。
このようにして、自分が受け取る分はしっかり受け取って外部に転送させないようにします。
そうしないと永遠にメールが世界中に転送され続ける事になりますので。
自身が受け取るメールは、「ローカル配送」と言って、続くMDAによってメールボックスと呼ばれるファイルやデータベースに、ユーザー毎に格納されます。ここでいうユーザーとは、Toアドレスのうち＠より前の部分で定義されたテキストで識別されます。
ちなみに、UNIX系OSでおなじみの /etc/aliases は、ここでいうユーザーを定義したリストの実装例の１つです。
もしユーザーが登録されていない場合は、ユーザーが見つからないという理由で、メールを送り返します。
返送先は、メールに記載されているReturn-Path（返送先）か Fromアドレスです（これは実装方式で動きが異なります）。
なお、返送と書いていますが、実際には元のメールを元に新たにメールを作成して、メールを配送する動きです。
これもメールの特徴的な機能ですね。「返送」という機能ではなく、送信元に「新たにメールをする」というかたちで、メールの仕組みをシンプルに実装しています。
MRA（Mail Retrieval Agent） ‥メールボックスの情報をMUAに渡す
メールボックスに割り振られたメールは、MRA（Mail Retrieval Agent）という仕組みを経て、MUA（メーラー）に渡されます。
MUA（メーラー）は冒頭で出てきた通り、OutlookやGmailなどのアプリケーションですが、それらアプリケーションから見ると「受信する先」がこのMRAになります。
この受信する先とは、POP3サーバー、IMAPサーバーという名前で呼ばれているものです。
- 受信メールサーバー名（ホスト名）
- ポート番号
- ログインＩＤ
- ログインパスワード
このような情報をメーラーに設定していると思いますが、これ届いたメールを受け取る窓口（MRA）なのです。
渡し終えたメールは必要に応じメールボックスから削除しますが、これもMRAの役割です。
MRAの実装としては、Dovecot、imapdといったものがあります。
メールの機能に関するまとめ
メールというのは元々MTAに相当する部分から始まり、歴史的経緯から徐々にセキュリティに関する機能強化をされていった、というところがおぼろげにでも知っていただけたのではないかと思います。
もちろんメールの機能というと、配送以外にメッセージのフォーマットをどう扱うか、といった面でも多くの進化がありましたが、それはまた別の機会にお話したいと思います。
お問い合わせ、ご相談を受け付けております
今回はどちらかというとエンジニア向けのお話になりました。
当社はアプリケーション開発を主業務として行っており、インフラ面、ミドルウェアといったところを主体で受け持っているわけではありませんが、必要なスキルとして身につけていて、社内でも共有してスキルアップを心がけています。
こういう事を知っているのと知らないのとでは、開発時はもちろん保守や運用サポートを行う段階での提案や問題解決力は変わってきますからね。
そういうこともあり、関係値のあるエンジニアさんからもこのような相談をもらったりします。
ということで、エンジニアさんからのお問い合わせやご相談も随時お受けしてますから、お気軽にご相談下さい。
なお、「ＩＴ相談役」というサービスであればリーズナブルにご利用いただけると思います。
初回のお問い合わせやご相談は無料です。
何か少しでも気になる事があれば、お気軽にお問い合わせください。