第２章

メールの仕組みと課題

図表２－１の説明１

要素

Mail Transfer Agent （MTA : メール転送エージェント）メールを異なるメールシステム間で転送する役割を持ち、他の MTA や MSA と SMTP プロトコルなどを利用してメールの送受信を行う機能を提供します。
メールの宛先に応じて転送する先を振り分ける機能や、受信側のシステムで受信する準備ができていない場合などに一時的にメールを保存（キュー）する機能などを持ちます。一般にサーバ・アプリケーション・プログラムとして実装されます（例： sendmail 、 Postfix 等）。
Mail User Agent (MUA : メール・ユーザ・エージェント)エンドユーザがメールを作成し、送信する（MSA にメールを投稿する）機能や、受信したメールをエンドユーザが読む（メール・スプールから読み出し、表示する）ための機能を提供します。
MUA から MSA へのメールの送信は、一般に SMTP プロトコルを利用して行われます。また、メール・スプールからの読み出しは、 Post Office Protocol 3 （POP 3） や Internet Message Access Protocol 4 （IMAP 4） プロトコルを利用して行われます。
一般的にエンドユーザの端末上で動作するアプリケーションとして実装され、メールクライアント、メールソフト等と呼ばれる場合が多いです（例：Microsoft 社の Outlook や Mozilla の Thunderbird 等）。
Mail Submission Agent （MSA : メール・サブミッション（投稿）・エージェント）エンドユーザにより作成されたメールを MUA などから受信し、メールの配送を開始する機能を提供します。
MTA の役割をもつサーバ・アプリケーション・プログラムが MSA を兼ねる場合もあります。 MSA から MTA へ SMTP プロトコルを利用してメールを送信すると、 MTA は、次の配送先（他の MTA や MDA ）へメールを転送します。
Mail Delivery Agent （MDA : メール・配送・エージェント）メールの受信側（宛先）で、MTA からメールを受信し、メール・スプールへメールを保存する機能を提供します。
MTA の役割をもつサーバ・アプリケーション・プログラムが MDA を兼ねる場合もあります。
Mail Spool （MSPOOL : メール・スプール）メールの受信側（宛先）で、エンドユーザが MUA を利用してメールを読み取るためにメールを保存する機能を提供します。
Mail Box と呼ぶ場合もあります。
２処理
①
②
③
④
⑤
⑥⑦

ドメイン example.com のエンドユーザが、 MUA を利用してメールを作成エンドユーザは、 MUA を操作し、 MSA にアクセスしてメールを送信（投稿）MSA は、受け取ったメールを MTA へ配送MTA は、宛先ドメインの MTA を見つけ出して、その MTA へメールを配送受け取った宛先ドメインの MTA は、内部の MDA へメールを配送MDA は、メール・スプールへメールを届け、メール・スプールでメールを格納宛先のエンドユーザは、MUA を利用してメール・スプールへアクセスし、自分宛のメールを読み出す③④⑤のメールの配送では、複数の MTA を経由する可能性があります。最近では、アンチウィルスフィルタや迷惑メールフィルタなどを運用しているドメインも多く、そうしたフィルタを用いたフィルタリングは MTA で実施されている場合が多く、１つのドメインの内部であっても複数の MTA を経由してメールが配送されることが一般的になっています。
また、④で宛先ドメインの MTA を探すときに、送信元の MTA は、宛先ドメインの DNS 上の MX レコードを参照します。 MX レコードとして登録されているホストは、そのドメインにおいて外部ドメインからのメールを受信する役割をもつホストと解釈されます。

7

第２章

メールの仕組みと課題

2.2 メール配送の手順を相手方に送信し、相手方がそれに対する応答を返信するやりとりを繰り返すことにより手続メールを宛先に届けるための配送手順として、SMTP (Simple Mail Transfer Protocol, RFC5321)

受信側へ処理を伝えるので、ほとんどの場合、が使われます。

送信側が受信側に実行したいコマンドを送信す

メール配送では、メールを送りたい側 (送信側)が、メールを届けたい先 (受信側) にネットることになります。
このときの接続の方法やメールの受け渡し、ワーク的に接続を要求し、受信側が要求を受理受信側からの応答の仕方などを決めたものがすることにより、一連の配送手続が開始されまSMTP です。SMTP での手続の一般的な流れを図す。そして、実行したいコマンド名とその引数表２－２に示します。

図表２－２

SMTP によるメール通信手順

送信側では、処理の内容を示すコマンド(MAIL, RCPT, DATA など) を、引数とともに受8が進みます。なお、メール送信は、送信側からに対する応答という形で、受信側の判断や意図を送信側に伝えることができます。信側に伝えます。例えば、MAIL FROM で送信者のSMTP の規格（RFC5321)では、送信側が指定す情報（メールアドレス）を、RCPT TO で宛先の情る各コマンドの形式や順番、それぞれのコマン報（メールアドレス）を、DATA でメール本体のドに対して受信側が返すことができる応答番号情報を伝えます。

の種類などが定められています。

受信側では、それぞれのコマンドを解釈してこうしたメールの配送時に指定される、送信応答をします。コマンドに対する応答の種別は、者や宛先のメールアドレスなどは、郵便の手紙数字 (220 や 250 などの 3 桁の数字) で示されになぞらえてエンベロープ(封筒)情報とも呼ばます。例えばメールを受け取れない場合には、れます。

否定的な応答番号 (500 番台の数字) を返すこ

なお、SMTP は、メールサーバ間の配送時だけとになります。受信側は、このようなコマンドでなく、利用者がメールを作成する MUA (メール

第２章

メールの仕組みと課題ソフト) からメール投稿サーバ (MSA) への送字列で表現され、専用の区切り記号は決められ信時にも使われます。

ていませんが、文字列の構成方法によって区別ができるように決められています。

2.3 メール本体の構造

ヘッダ領域は、メール本体の先頭からヘッダ行が連続する領域で、ヘッダ行ではない空メール本体は、送信側が DATA コマンドを送信し、受信側がその応答として "354" を返した

行 (改行だけの行) がメール本文との区切りとなります。場合に、送信側から送信されます。メール本体

メール本文は、ヘッダ領域の区切り(空行)の最後に、ドット ('.') 文字だけの行（ドット行）から、メール本体の末尾までとなります。メが送信されます。なお、この場合のドット行は、ール本体の例を図表２－３ に示します。

メール本体には含まれません。
メール本体は、ヘッダ領域とメール本文によって構成されます。いずれの領域もテキスト文

図表２－３

メール本体

ヘッダ行は、ヘッダ名と続くコロン (':')、ールの配送時に指定される送信者情報（エンベヘッダ本文で構成されます。ヘッダ行はそれぞ

ロープ情報に含まれる送信者情報）と、メールれ形式や構文が決まっており、ヘッダを追加す本体のヘッダ領域に記述される送信者情報の 2

る場合には、正しく構文に従って記述しなけれ種類があります。これらの送信者情報は、メーばなりません。

ルで利用される情報なので、いずれも、メールなお、メール本体の構造及びヘッダ行の構文アドレスで示されます。

については、SMTP の規格（RFC5321）とは別に、Internet Message Format (RFC5322, インター2.4.2メール配送時に指定される送信者情報ネットメッセージの形式)で決められています。
メールの配送時に指定される送信者情報は、2.4 メールの送信者情報

図表２－２ で示した MAIL コマンドの引数として指定されるメールアドレスです。このメー

2.4.1 概要

ルアドレスは、配送上で何か問題が発生した場合に送信者に通知を送る際に利用されます。そメールの作成者や送信者を示す情報には、メのため、リバースパス (reverse-path) という

9

第２章

メールの仕組みと課題名称が付いています。リバースパスは、SMTP にールを送信してきた送信者であった場合などによるメールの配送時に渡される情報なので、一は、受け取らないことを応答コードで示すこと

般にはメールの受信者には渡されない情報になができます。また、受信側の MTA が、一旦メーります。

ルを受け取った後で、MDA (Mail Delivery Agent)

なお、受信側の MTA は、この MAIL コマンド上でメールスプールに保存ができなかった場合に対する応答として、メールを受け取らないこや宛先が実際には存在しなかった場合など何らとを示すエラーコードを返すことができます。

かの問題があった場合には、このリバースパス

例えば、指定されたメールアドレスが明らかに宛にエラーメールを送信することになります。

実在しないものであった場合や、過去に迷惑メ

図表２－４

エラーメールの送信例

2.4.3 ヘッダ領域に記述される送信者情報

Agent, メールソフトウェア) の多くは、全てのヘッダを表示しません。送信者情報を示すヘッ

ヘッダは、メール本体の一部として受信者にダの仕様としては図表２－５に掲げるものがあ届けられるため、受信者が見ることのできる情りますが、MUA が送信者情報として表示する情報です。しかし、ヘッダにはたくさんの種類が報は、通常は From ヘッダになっています。

あるために、受信者が利用する MUA (Mail User

ヘッダ名

用途Sender

メール送信を実際に行った送信者を示す情報

From

メールの作成者を示す情報

Reply-to

返事を送信する場合の宛先を示す情報

図表２－５10

ヘッダ上の送信元アドレス

Sender ヘッダが最も良く使われるケースとするプログラムなどが配送しています。そのたしては、メーリングリストがあります。メーリ

め、Sender ヘッダにはメーリングリストの管理

ングリストでは、リストへの投稿者が From ヘ者などのメールアドレスが示されることになりッダに示されます。しかし、リストメンバへのます。また、今ではあまり行われないかもしれ送信は、実際にはメーリングリスト機能を実現ませんが、例えば実際のメール内容の作成者に

第２章

メールの仕組みと課題代わって秘書がメール送信するような場合に、送信者のメールアドレスを Sender ヘッダに示

2.5 送信者情報詐称の問題されることがあります。
From ヘッダの使われ方にも注意すべき点が2.5.1送信者情報詐称を判断する仕組みあります。From ヘッダには、メールアドレス以外にも、補助情報としてディスプレイネーム

メールシステムにおける送信者情報には、2.4(display-name) を追加することができます。デでみたように、用途に応じた複数の種類がありィスプレイネームには、任意の文字列を使用でます。しかし、これまで、いずれの送信者情報きますので、From ヘッダ上に示されたメールアについても、それが正しく名乗られているかをドレスと全く関係の無い名前や文字列が使えま判断する仕組みがありませんでした。もともとす。MUA や Web ブラウザでメールの送受信を行の電子メールシステムは、インターネットが現ういわゆるウェブメールシステムの多くは、送在のような形で普及する以前から存在してきた信者情報として、このディスプレイネームを優システムであり、メールの利用者が限られてい先して表示しますので、送信者情報として表示た時代から少しずつ拡張されて使われて続けてされる文字列は、実際の送信者情報とは全く関いるために、現在のように送信者情報が詐称さ係が無いかもしれないものとなっているのです。

れることを予め想定していなかったためです。

図表２－６

なりすましメール送信例

11

第２章

メールの仕組みと課題

そのため、これまで受信側では、経験的な運頼性のある送信者を騙り、メールに添付された用方法として、例えば、送信者情報として、存不正プログラムを実行させ、外部からコントロ在しないドメイン名が指定された場合や、日本ールされるボットにされたり、PC 内部にある個の有名ドメインを名乗っているものの海外など人情報や操作過程で得られる個人情報を搾取す

明らかに異なった送信元からのメールだった場るなどの行為が行われています。

合に受信を拒否するなどの工夫をしてきました。

さらに、迷惑メールは宛先が存在するかどうしかし、それらの場合であっても、ドメインかにかかわらず大量に送信される傾向にあるた名を管理する DNS(Domain Name System) が単にめ、リバースパスを詐称し、実在するメールア不調であったり、海外からメール転送をしていドレスを指定している場合に、宛先が不明であたりする場合など、ごくまれに送信者情報を故ることによるエラーメールが、詐称されたメー意に偽装したものではない、正しい送信であるルアドレスに宛てて大量に送信される、バック場合があります。

スキャッタ (backscatter) が大きな問題となってきています。その場合には、そのエラーメ

2.5.2 送信者情報詐称の問題点

ールが迷惑メールと判断され、迷惑メール判定機能を提供しているベンダやブラックリストをメールの送信者情報が詐称されることによって、様々な問題が出てきています。

運営している組織に報告され、正しい処理としてエラーメールを送信している側（最初のメー

まず、受信側で、迷惑メールを受信しないたルの受信側）が、迷惑メール送信者として登録めに、送信者情報をもとに受信を拒絶しようとされ、同じ出口から送信される通常メールまでしても、詐称されていることにより、的確に受もが、迷惑メール扱いされて届かなくなる、と信の拒絶ができないことがあります。

いう 2 次的な問題も発生しています。

また、実在する送信者を詐称し、実物とは異なる偽のウェブサイトに誘導し、個人情報を搾取するなどの犯罪行為 (フィッシング) や、信

図表２－７

12

バックスキャッタ問題

第２章

2.5.3 送信ドメイン認証技術

メールの仕組みと課題問題が生じています。これに対応するために、送信ドメイン認証技術が開発されており、そのこのように、送信者情報が簡単に詐称できてしまい、それを受信側で簡単に判断することが普及により、送信者情報詐称の問題点を防ぐことが可能になります。

できない現在のメールの仕組みにより、大きな13