eメールの理解

このテキストについて

このテキストは次の授業で使用されている標準化された教材です。

実際の授業では解説が加わる上に、生徒様に合わせて教材は制作・調整されるため、 このテキストよって得られる理解がMimir Yokohamaの授業のすべてではないことを予めご理解ください。

eメールの概要

はじめに

「コンピュータを使ったメッセージの送信」というアイディアは、実に17世紀まで遡り、19世紀にはそのアイディアは実現されました。

現在に至るeメールの原型は少なくとも1966年には異なるコンピュータ間でのメール転送が実現されていたことが分かっています。 コンピュータの利用法としても、またネットワークの利用法としても、最古のもののひとつとなっています。

eメールはRFC822で定義されました。 eメールに関するRFC文書はとても多いのですが、主に重要視されるものは、メールコンテンツを規定したRFC2822と、メールアドレスを規定したRFC5321及び5322です。

“eメール”とはなにか

ごくシンプルに言えば、電子メッセージですが、 通常、eメールと言った場合には少なくともRFC2822形式に従ったデータフォーマットのメッセージを指します。

“インターネットメール”の意味で使われることが多く、混乱を招きますが、 実際のところ必ずしもインターネットで使われるものではありません。 eメールはインターネットよりも歴史が古く、UUCPネットワーク1の中でも使用されていました。 Unixシステムではシステムメッセージとしても使われています。

ユーザー間で通知を行う方法がそのままインターネットまで拡張されていると理解したほうが良いでしょう。

eメールの仕組み

メールサーバーと配送

メールの配送を担うのはMTAと呼ばれるプログラムです。

MTAはeメールを受け取り、そのeメールが自ホスト宛であればMDAに渡し、他ホスト宛であればそのホストにメールを転送します。

これは郵便と同じようなものだと考えることができます。 郵便は、その郵便局が配送すべきものなら配送し、そうでないならば配送すべき郵便局に送ります。

MTAに対してメールを送信する際にはTCP 25での送信を行います。プロトコルはSMTPといいます。 リモートホストからの配送を受け付けるサーバーをsmtpdと呼びます。

MTAに対してメールを送信する方法としては、SMTPだけでなく、そのコンピュータからコマンドによって送信することもできるため、必ずしもメール配送にsmtpdが必須であるわけではありません。 現代の一般ユーザーはSMTPをメール送信に使うため、「SMTPは送信」という説明がなされることも多いのですが、実際はsmtpdはメール受信のためのサーバーです。

SMTPがTCP 25であることはeメールの古さを物語っています。 必ずしも古い順に割り当てられたわけではありませんが、おおよそ古いものほど小さな番号のポートを使用しています。 現代でもよく使われるwellknown-portは次のようになっています。

TCPポート番号プロトコル目的
20FTPファイル転送(データ転送用)
21FTPファイル転送(コントロール用)
22SSHセキュアログイン
23Telnet平文の通信/ログイン
25SMTPeメール転送
42WINSWindows用の名前解決サービス。Windowsドメインで使用
43Whoisドメイン情報の検索/問い合わせ
53DNSドメイン名の問い合わせ
79Fingerユーザー情報の問い合わせ
80HTTPウェブ
110POP3eメールの取得
143IMAPeメール情報へのアクセス

ネットワークeメールが規格化される以前はFTPでファイルを送受信する形でメッセージをやりとりしていました。

MTAは受け取ったメールをキューに入れます。 キューは入った順に処理され、転送、またはMDAに渡されます。 通常、同時に複数のメールを扱うことはありません。

MDAは指定されたユーザーのメールボックスにメールを保存します。

送信・受信・配送

MTAはSMTPによってメールを受け取ります。 本来SMTPはMTA間の通信プロトコルであり、ユーザーはユーザーのコンピュータで動いているMTAによってメールを送信するものでした。

しかしインターネットが一般化したことにより、「コンピュータの内部でサーバーを動かす」というモデルを採用しない「パソコン」が普及し、それがインターネットの一員である状況となりました。 このようなコンピュータがメールを送信する方法として、「他ホストのsmtpdに対してsmtpでメールを送る」という手段が取られました。

そもそも、eメールは「一度で送る」ことを想定しているわけではありません。 物理回線のことを考えても、いきなり送るのは難しかったのです。

国をこえてメールを送ろうとすれば、1通の処理に何分もかかる、ということも普通にありました。 もしMTAが無条件に目的のホストに送信しようとするならば、「キューを順に処理する」ため、そのような「通信が届きにくいホストへのメール」が集中するといつまでたってもメールを配送できない事態に陥ります。

そのため、条件によっては確実に配送できるホストに対して送信するということが行われたわけです。 この仕組みを使って、「配送を依頼するホストにメールを送信する」という形でユーザーが直接SMTPによってメールを送信するという形がとられるようになりました。

これは形態としては「メールサーバーが外部にある」状態を生じたと言うこともできます。

これ以前としては、特殊な人を除けばネットワークにつながったコンピュータは主に大学のコンピュータでした。 ユーザーは大学のコンピュータに(rlogintelnetなどでログインし)メールを送信し、あるいはメールを読みます。

この際に使われていたのはUCB Mailというソフトウェアでした。

そのシステムのメールスプールにあるメールを読むにはmailコマンドを実行し、 対話的操作でメールを読み、あるいは保存します。

$ mail
"/var/mail/user01": 10 messages 1 new 1 unread
>R   1 user02        Tue Jun 17 11:10  18/584   Test1
U   2 user02        Tue Jun 17 11:25  17/560   Test2
N   3 user02        Tue Jun 17 11:40  15/539   Test3
&

メールを送信する場合もmailコマンドを使います。

$ echo "Hello, how are you?" | mail -s "TestMail" jrh@example.net

この大学にあるコンピュータはインターネットに接続されており、smtpdを通じて外部ホストからメールを受け取ります。 この大学のコンピュータにメールが到達することが「受信」であり、受信したメールは大学のコンピュータにログインすることで読むことができます。

ではパソコンスタイルではどうなるでしょうか。

メールは今までどおりメールサーバーにsmtpdを通じて配送されますが、パソコンではメールの送信はパソコンのMUA(Mail User Agent)を通じてメールサーバーに送信しています。 対称性という意味でも、「メールサーバーからメールを取得してパソコンで読む」のが自然であり、実際にMUAはパソコンに保存されているメールを読む機能があります。

そうなるとユーザーが認識するエンドポイントはメールサーバーではなくパソコンになります。 メールサーバー側でも一般に向けたサービスとなればその全員にログインアカウントを発行することは憚られることであり、その意味でもメールサーバーはあくまでメールを仲介する存在となっていきます。

これに伴って登場したのがPOP(Post Office Protocol)です。 POPは主にversion3が使用され、version1/2は互換性のないレガシーなプロトコルです。 プロトコルに関する知識がある人もほとんどいないでしょう。

POPの仕組みはクライアントプルです。 POP接続を受け付けるサーバーはMRA(Mail Retrieval Agent)と呼ばれます。 MRAはユーザーMUAからの接続を受け付け、メールを転送します。

しかし、この仕組みを採用したためにeメールはエンドポイントに配送されるものではなくなりました。 郵便で言えば、メールサーバーは郵便局であり、「受信したメールは私書箱に配送される」仕組みになります。 ユーザーは受信したメールを郵便局まで取りに行く必要があります。

ところが、MUAにおいてメールを取得することを「受信」と呼ぶために、混乱が生じました。 メールが配送・到達することと、手元のコンピュータにメールが保存されることを混同する事態となったのです。 eメールとしてはメールサーバーにメールが届いていれば、それは「配送されている」のであり、ユーザーはアクティブに自らメールを取りにいかねばなりません。

さらなる混乱は携帯電話のeメール(キャリアメール, MMS)が端末まで配送されるように見えることによってもたらされました。 初期はキャリアのメールサーバーにメールが到達した時点でショートメールでメールが到達したことを伝えるものでしたが、やがて電話回線を使って特殊な電波を送ることで端末にメールサーバーにメールがあることを通知し、端末はそれが通知されると裏でメールを取りにいくという仕組みを採用していました。 この操作は裏で行われ、ユーザーに意識させないため、一見メールは端末まで配送されているように見えます。

SMTPと認証とスパム

PbSとSMTP-AUTH

MTAの役割はメールを配送することであり、その配送にはSMTPを用います。 ネットワーク回線に十分な速度がなく、信頼性もなかった時代に生まれたものですから、 リレーすることでなんとか届けよう、というのが基本的な考え方です。

そのため、MTAは基本的にオープンリレーでした。 どこから送られてきたメールであってもとりあえず受け取り、他ホスト宛のメールを受け取ったならば配送しようとするというものです。

ところが、インターネットが商業化されるとたちまちこの方式に問題があることがわかりました。 スパムメールやウィルスメールの蔓延です。 身元の確認もせずとにかく受け取って届けようとするという方式はスパムメールやウィルスメールに対する抑止力を全く持っていませんでした。

ネットワーク回線の信頼性と速度の向上に伴って、このようなオープンリレー方式は廃止され、SMTPサーバーは「信頼できるユーザーからのメール、または自ホスト宛メールのみを受け取る」という方式に転換していきました。

問題は信頼できるユーザーからのメールの判定方法です。 そもそもオープンリレーを前提としたSMTPには認証機構はありません。

メール受信に関しては他の人のメールを勝手に読まれてはなりませんから、当初から認証がありました。 そこでこれを活用した方式が考案されました。 「POP3によってメールを受信したホストのIPアドレスを記憶し、POP3の認証後一定時間メールの配送を受け付ける」というものです。 これを“POP before SMTP”といいます。

しかし、IPアドレスを元にするというのは雑な方式で問題がありました。 特にNATを使ったアクセスの場合、ルーターの向こう側にいる人は全て同じアドレスが振られています。 学校や会社などひとつのゲートウェイを共有している場合にはそのうち誰かひとりが認証すれば他の人もメールを遅れる状態になります。 かなり牧歌的なセキュリティだと言えるでしょう。

そこで1999年に標準化された2SMTP-AUTHによって直接的にSMTPにおける認証が行われるようになりました。

SMTP-AUTHは汎用の認証メカニズムであるSASL(Simple Authentication and Security Layer)を使用しています。SASLはPOP3やIMAPにおいても用いられているものです。

OP25Bとサブミッション

SMTP-AUTH導入はスパムメール抑止に効果を発揮しましたが、それでも十分ではありませんでした。 スパムメールは増え続け、問題はより深刻化していきます。

この対策として登場したのがMSA(Message Submission Agent)とOP25B(Outbound Port 25 Blocking)です。

MTAの原則は「メールコンテンツは見ない、触らない」です。 行えるのは経路情報への追加だけです。

MSAはMUAからメールを受け付け、メールコンテンツの補完・修正を行います。 主流となっている設計ではSMTP-AUTHによる認証はMTAではなくMSAに持たせ、メールヘッダによるメール審査などもMSAが行います。 MSAが審査した上で通したメールをMTAが配送する方式ですが、実際はMTAとMSAはコンポーネントとして別れておらず、その区別は不明瞭なのが一般的です。 同一のソフトウェアでも複数のメールサーバーによって多段化してMSAとMTAに分離することは可能です。これは、「ソフトウェアの違い」ではなく「役割の分離」です。

MSAが受け付けるべきSMTPポートとしてTCP/587が規定されています。 これを「SMTPサブミッションポート」といいます。

「認証されないことを前提として送信者を偽装して送信する」ということがよく行われ、 Submissionによる審査とSMTP-AUTHによる認証を必須とするため、メール配送に使用するTCP/25をISPにおいてブロックするという取り組みが行われています。これがOP25Bです。

インターネットへの接続はISPを通じて行いますが、透過的ゲートウェイで宛先ポートがTCP/25であるパケットを捨てます。これによりユーザーはTCP/25に対する接続が不可能になります。 ユーザーはサブミッションポートを通じてsmtpdにメールを送信する必要があります。

これによる弊害もあります。 ISPを通じてインターネットに接続しているネットワークにMTAを配置して外部にメールを配送することができなくなりました。 「自宅サーバー」が流行ったことがありますが、現在は社内にメールサーバーを置いて一括してメール運用するようなことは困難になっています。OP25Bを実施するISPを介在しない、VPSサービスなどを使うのが無難でしょう。

SPF

迷惑メール対策としてはさらにSPFやDKIM, Sender IDなどがあります。

SPFは

というものです。

Mimir YokohamaではSPFレコードは次のようになっています。

$ dig mimir.yokohama TXT

; <<>> DiG 9.11.2 <<>> mimir.yokohama TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3016
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;mimir.yokohama.            IN  TXT

;; ANSWER SECTION:
mimir.yokohama.     3599    IN  TXT "v=spf1 +ip4:150.95.217.78 +ip6:2400:8500:1302:912:150:95:217:78 ~all"

;; Query time: 141 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: 火  1月 09 18:49:20 JST 2018
;; MSG SIZE  rcvd: 124

これは「IPv4ならば150.95.217.78, IPv6ならば2400:8500:1302:912:150:95:217:78から送られたメールであれば本物で、それ以外のサーバーから送られたものは全て偽物なので捨てよ」ということになります。

SPFを使用するメールサーバーで有名なものはGmailです。

SPF認証を採用した場合、

2011年時点の情報ですが、30%のメッセージはSPFに正しく対応していないという理由でメッセージが正当なものであるか否かに関わらず破棄される結果になります。 一方、70%のメッセージはSPFに対応したドメインから送信されており、この中で送信者偽装したものは捨てられることになります。

迷惑メール対策としては大変効果がありますが、送信者には気づかない形で捨てるメールが発生するため躊躇する要素もある技術です。

エンベロープとコンテンツ

メールは「エンベロープ」と「コンテンツ」に分かれています。

エンベロープはSMTPコマンドであり、2つのコマンドが使用できます。

MAIL FROMは送信者アドレスです。 何者が送信したメールであるかということをMTAが記録します。 MTAが直ちにそのメールを拒否し、そのことをメールによって通知する場合、このアドレスに対してメールで回答します。

RCPT TOは宛先アドレスです。 MTAはこのコマンドによってそのメールの配送先を認識します。

メールエンベロープが受信者の目にふれることはありません。

メールコンテンツはメール本文です。 メールヘッダはメールコンテンツに含まれています。

メールヘッダは書き方こそ決まっているものの、自由記述であり、MTAはメールコンテンツには原則触れません3。 つまり、From:という項目も自由に書くことができるということで、これはあくまで「受け取った相手に対する名乗り」でしかありません。メールサーバーには関係のない部分です。

MUAではおなじみのBCCですが、これはヘッダにも含まれないものです。 CCはメールヘッダに記述するCCという項目ですが、BCCに関してはメールコンテンツには何も記述せず、MUAがRCPT TOに加えるアドレスの記述に使われています。特にBCCという名前が決められているわけではなく、その名前が使われることもありませんが、慣例としてBCCと呼ばれています。

メールアドレス

インターネットメールアドレスは

local@domain

という構造を持っています。 domainは宛先ホストの名前であり、localはホスト内で識別されるユーザーあるいはメールボックスの名前です。

インターネットメールアドレスはRFC5321/5322で規定されています。 メールアドレスの仕様についてはWikipediaに詳細な記述があります。4

この中で重要な点ですが、ローカル部の.は特別な扱いであり、

という仕様になっています。

ところが、Docomoがこのようなメール形式を許し、しかも「迷惑メール対策として有効である」として広まったため、「RFCに違反し正しくないメールアドレスであるにも関わらず実効性のあるアドレス」が氾濫することとなりました。5

このようなメールアドレスは配送に問題をきたす可能性があります。6

MTAはメールアドレスを配送すべき宛先ホストをRCPT TOdomain部分を見て判断しています。 また、MTAは受信したメールについてRCPT TOdomain部分で自ホスト宛か否かを判断しています。 自ホスト宛と判断された場合、RCPT TOlocal部分を見て配送すべきメールボックスを探索します。

このようなメールアドレス形式はインターネットメールに限ったことであり、MTA及びMUAはこれ以外の形式のメールアドレスを扱う可能性を考えなくてはいけません。

最も典型的にはシステムローカルなメールです。 コマンドによってMTAに送られたメールはdomain部分を持たないメールアドレスである可能性があります。 これは書かれているアドレスがメールボックス名であるとみなします。このような宛先のメールをSMTPごしに受け取るかどうかはMTAの設定によります。

もうひとつはbang path(バンパス。バングパスとも)形式のメールアドレスです。 これはUUCPで用いられていたもので、全ての経路を!で連結して記述します。 例えば!{seismo,ut-sally,ihnp4}!rice!beta!gamma!meというbang pathの場合

  1. メールはseismo, ut-sally, ihnp4のいずれか接続できるホストに送られ
  2. 送られたホストはriceに転送
  3. ricebetaに転送
  4. betagammaに転送
  5. gammaは自ホスト宛メールとしてmeというメールボックスに配送

ということになります。 現在bang pathを扱うことはないでしょう。

Microsoft Japanの罪深さ

Microsoft Windowsに付属するMUAの“翻訳”がユーザーのメールに対する理解を妨げる問題となっています。

Microsoft Outlook Expressに関しては「開封確認機能の実装」「HTMLメールの採用」など利用者が「迷惑だ」と感じる機能を実装した上に広めたこと、さらに重大なセキュリティホールとして機能しつづけたことなど非常に罪深い存在になっています。

システムメール

Unixでは伝統的に、なにか問題が起きたときにはユーザーにメールを送信するということになっています。 メールはMTAによってメールボックス(メールスプール)に配信されます。 伝統的にはログイン時に未読メールがあることが通知され、mailコマンドで確認するという流れでした。

しかし近年はシステムメールは急速に使われなくなっています。

これはいくつかの要因が重なっています。

一般ユーザーはメールを受け取る(smtpdを使用してMTAがメールを受信する)ことは基本的にないという考え方や、さらにメールの送信は外部のsmtpdにMUAで接続するという考え方、それを補強するOP25Bの存在などから外部に対する攻撃性のあるセキュリティリスクであるsmtpdを停止するという考え方になり、その結果複雑でメンテナンスしにくいMTAを廃止するという流れがありました。

sSMTPはそのような流れの中で流行したソフトウェアです。 sSMTPはMTAではありません。メールを送信するsendmailコマンドを置き換えて、メールはすべて他のMTAに配送を依頼するという方式を取っています。

これはローカルのMTAを用いてメールを配送する代わりの手段として使うことができますが、ローカルメールの配送機能がありません。サーバーとして多く使われるRedHat Enterprise LinuxがMTAを廃止してsSMTPを採用したことで「システムメール廃止」の流れが加速しました。

IMAP

IMAPはメールサーバー上のメールボックスにアクセスするためのプロトコルです。

現在使われているIMAPはプロトコルバージョン4で7、TCP/143を使用します。

POPがメールを端末にダウンロードするためのものであるのに対し、IMAPはメールをサーバーに置いたまま閲覧・操作するためのものです。 仕様としてメールフォルダをサポートしており、サーバー上でメールを整理することができます。

POPが基本的に一括操作を想定しているのに対し、IMAPは部分操作を想定しています。 「ヘッダのみの取得」がプロトコルの一部として標準化されていますし、マルチパートメールのテキスト部分のみを取得することもできます。操作のたびに通信が発生するという意味では通信量を増加させますが、必要なときに必要な部分のみにアクセスするということでは通信量を削減します。

IMAPを通じてメッセージを検索することができます。この場合、メッセージの検索はサーバーによって行われ、IMAPを通じて結果が返されます。検索のリソースはサーバーのものが使われるため、非力なクライアントでは負荷軽減に寄与します。

MUAでメールを読み込み、読み込んだ内容を端末上に保存することでメールのダウンロードも実現できます。 また、トランザクションをサポートするため、オフラインでメールを操作し、オンラインとなったときに一連の操作をIMAPでサーバーに送信することで操作を反映するということも可能です。

IMAPを使用する場合はメールがサーバーにたまりがちであることに注意する必要があります。 一般的にメールボックスには容量制限があり、特に添付ファイルなどによって容量を圧迫し、メールボックスが溢れる可能性があるためです。 また、大量のメールをためこむと通信量が増大する可能性があります。

ウェブメール

ウェブメールはメールサーバー上のメールをウェブアプリケーションを介して閲覧、操作することのできるソフトウェアです。

メールをサーバー上に蓄積するという意味ではIMAPに近い存在ですが、メールのダウンロードはIMAPと比べ困難で、部分操作もIMAPほどの柔軟性はありません。 MUAを選択することもできませんし、機能的には基本的に見劣りのするものです。

しかし、ウェブメールが人気であることについてはそれなりに理由があります。

一時期非常に要望の強かったウェブメールですが、スマートフォンの普及によってウェブメールの利用者は少し減りました。

メールソフトウェア

MTA

MTAは伝統的に使われてきたものとしてSendmailがあります。

Sendmailは複雑で巨大な単一のソフトウェアです。 eメールの黎明期からeメールを支え続けたソフトウェアですが、

といった問題から負担が大きく、危険性も高いソフトウェアでした。

唯一といってもいいMTAとして君臨し続けたSendmailですが、1997年以降、設定・運用ともに負担が大きく、セキュリティ的にも問題のあるSendmailを置き換える動きが発生します。

qmailはセキュリティを重視したMTAです。 作者であるDaniel Julius Bernstein氏が一人で開発・公開しつづけてきたものです。

qmailはセキュリティに優れ、Sendmailよりも効率的でシンプルで管理しやすいという特徴を持っていました。 一方でSendmailとの互換性がなく、移行が難しいといった問題もあります。 ディレクトリ構成が独特であるという点も批判されがちでした。

早期に「完成形」とされ開発を終了したこともあり、qmailは現在のMTAの仕様を満たしません。 しかしながら依然としてかなりの数のqmailが現役で利用されています。 環境を問わず Eximは管理しやすく、軽量で、細かなコントロールが可能なMTAです。Sendmail互換で、Sendmailを期待するソフトウェアでも問題なく動作します。 GUI管理コンソールもあり、設定も比較的容易ですが、Eximを採用するメールサーバーはごく少数です。 qmailがツール郡からなるのに対し、EximはSendmail同様に単一のソフトウェアとなっています。

PostfixはSendmailとの互換性を保ちつつ、管理・設定が容易で高速・安全であることを目指したMTAです。 qmail同様にツール郡からなり、ディレクトリ構成もUnixらしいものです。

Sendmailの開発が事実上終了している現在、新しいメールサーバーは基本的にPostfixによって構築されています。

MTAのコマンドはSendmailにおいてはsendmailでした。 互換性を持つExim及びPostfixもsendmailコマンドを持ちます。 ウェブアプリケーション(特にCGIアプリケーション)でメールを送信する方法としてsendmailというコマンド名に触れた人も多いでしょう。

MRA

MRAはシンプルで管理しやすいqpopperが流行し、その後機能性を求めるサーバーではIMAPにも対応したCourier-IMAPに移行しました。それ以外の選択肢としてはCyrus IMAPもありました。

後発のDovecotが登場すると、管理しやすくセキュアであることからシェアを伸ばしていき、現在ではほとんどの場合新規採用はDovecotが使用されています。

MUA

名称プラットフォーム特徴
Outlook ExpressWinWindows標準メールソフトウェア。Windows98以降広く使用された。
Windows Live MailWinOutlook Expressの後継として採用されたソフトウェア。Windows Live!コンポーネントのひとつ
Windows MailWinWindows 8から採用された新しいMUA。タッチ操作などを想定したUIに変更されている
Mozilla ThunderbirdWin / Mac / UnixMozillaによるソフトウェア。クロスプラットフォームで使用できる
EudoraWin / Macかつて幅広く使用されていた人気MUA。現在はスマートフォン向けプロセッサで有名なQualcommが取り扱っていた。商用バージョンも存在。2007年に終了
Becky! Internet MailWin1996年という古参のWindows向けシェアウェアMUA。現在も開発は継続している。
SylpheedUnix / Mac / WinUnix環境向けの高速動作が特徴のMUA。メールボックスにはMH形式を採用、Windowsでも動作する。

メールボックス

mbox

mboxはメールをすべてひとつのファイルにまとめた形式です。 複数のフォルダがある場合は別のファイルにします。

mboxはmboxo/mboxrd/mboxcl/mboxcl2の4フォーマットがあります。

mboxp/mboxrdが一般的で、これらはメール先頭を

/^From/

であると識別します。

もしそのような行がメール内にある場合には

>From

と変形します。 もし>Fromではじまる行がある場合には>を増やします。

mboxcl形式はContent-Lengthヘッダによってメールの大きさを明示的に指定します。

Mozillaが採用するMboxはさらに発展的なフォーマットです。

Maildir

1メール1ファイルとして保存し、ファイル名にはユニークな名称をつけます。

メールフォルダ内にファイルシステムのディレクトリを作り、新着メールはnewディレクトリ、それ以外はcurディレクトリに配置します。

また、ファイル名は:に続いてフラグ情報を並べます。

ファイル名に:を使うため、Windows上では直接使用できません。

Maildir++形式ではサブフォルダも扱うことができます。

MH

MHはコマンドラインユーティリティであるMHで採用された形式です。

1メール1ファイル形式であることはMaildirと同様ですが、メールは1からはじまる連番です。

また、ファイルシステムのディレクトリがメールフォルダとなります。 メールボックスの概念をできるだけファイルシステムに近づけた形式です。

MIME

概要

eメールは原初からあるものですから、歴史と共に発展してきましたし、 今では考えられないような単純な構造をしていたりもしました。

例えばeメールの配送は8ビットクリーンではありませんでした。 これは、ASCIIは7ビット128文字を使用しており、1バイト中の上位1ビットは常に0です。 本当の意味でのASCIIコードは7ビット単位でそもそもバイト単位とは区切りが異なりますが、 通常ASCIIと呼ぶ場合は8ビットエンコーディングを指します。

ほとんどのコンピュータが扱う最小単位は8ビットであるオクテットであり、eメールにおいても8ビットエンコーディングのASCIIが使用されていました。 しかし、単にそれでは最上位ビットは常に0であり、無駄になってしまいます。 そこで、最上位ビットはパリティビットと呼ばれ、通信エラーチェック用に使われていました。 ASCIIにおいては最上位ビットは常に0であるはずで、これが1になっていたら通信エラーが発生していると判断する、ということです。このような挙動は通信アプリケーションにおいてはよく使われていたものでした。

西ヨーロッパ言語で使われているISO-8859-N文字集合は、ASCIIを拡張し、最上位ビットが1になる形で128文字を拡張しています。これは日本語のJIS X0201バイトエンコーディングも同様です。 また、ISO/IEC 2202を使用した文字エンコーディング(例えばJIS(ISO-2202-JP), EUC-JP, EUC-CN/GB 2312, EUC-KR)も最上位ビットが1になる可能性があります。

実際にこのような8ビットエンコーディングでのeメールは支障をきたすことが少なくありませんでした。 そもそも、eメールの規格として使用できるのはUS-ASCII文字列だけなのです。しかも、1行あたり1000バイトという制限まであります。

US ASCIIの文字列しか送れないeメールでやりとりするために涙ぐましいほどの工夫が凝らされました。 日本語においてはASCII文字列によるローマ字表記が使われましたし、バイナリファイルの送信はuuencodeやsharが使われました。

それでも、それはあまりにも不便なものです。 そこで様々なフォーマットを扱えるようにしようというのがMIME(Multipurpose Internet Mail Extensions)です。

MIMEは本質的に以下のようなものから成り立っています。

データ型を示すフィールドの導入

MIMEはパートという形で複数のコンテンツを持つことができるようにしています。

その中でそのパートがどのようなデータ型であるか、ということを示すフィールドが追加されました。これをMIMEタイプといいます。

MIMEタイプを含むcontent headerは以下のようなものです。

Content-Type: text/plain; chatset=UTF-8

これはMIMEタイプ(Content-Type)がtext/plainであることを示し、また文字エンコーディングとしてUTF-8が使用されていることを示します。

Content-Typeはタイプに/をつけてサブタイプを示します。 Content-Typeとしてはtext/plain, text/html, image/jpeg, message/rfc822などがあります。

このMIMEタイプは拡張子よりも明確にそのデータがどのようなものであるかということを示すことができることから、現在は非常に幅広く使用されています。

例えばweb/HTTPにおいてデータ型としてMIMEタイプが使用されており、Linuxデスクトップではデータの取り扱いを決める際にメディアタイプを表す方法としてMIMEタイプを使用しています。

本文の再帰的な構造化

Multipart/Mixed Content-Typeを使用すると boundary というパラメータが定義されます。

boundaryは指定された文字列を区切りとしてメールを複数のパートに分割します。 これにより、eメールに複数のメッセージ(例えば転送されたメールなど)や複数のメディアタイプのデータを含むことができます。

マルチパートの一部としてMultipart/MixedMessage/Rfc822を含むことができます。 これにより、異なる boundary を使用して階層化することができます。

安全な符号方式の定義

8bitのバイト列(文字列を含む)を7bitで表現するためにどのような方法で符号化しているかについて、 Content-Transfar-Encoding によって指定します。

従来はuuencodeがよく使用されていました。 uuencodeは8ビット3文字(24ビット)を6ビット4文字(24ビット)に変換します。 しかし、uuencodeはeメールで使用する上で安全性が保証されていない文字列を使用します。

MIMEによって追加されたBase64は使用する文字としてA-Za-z0-9+を選択しています。 これはPEMで定義されたprintable-encodingと同じもので、MIMEが異なる名前で採用しています。

Quoted-printableは8ビット文字やその他メールにとって危険な文字8の前に=をつけ、1バイトを16進数で表現します。

1バイトをASCII文字3文字で表現するわけですから、3倍の3バイトに変換します。 Base64と比べデータ量が増えてしまうように思えますが、西ヨーロッパ言語やPostScriptデータなど大部分がASCII文字で構成されているデータは符号化によるデータ量増加を抑制できます。

=で終端する場合、長い行を折り返したものとみなします。 一部メールデーモンやメールフィルタが1行80文字までと限定しているため、 それ以内に納めるように改行します。 このため、折り返しが必要となります。

エンコーディングとして7bitが使用された場合、安全なASCII文字列からなるとみなします。 8bitが使用された場合は最上位ビットを使用するテキストデータであるといううことになります。 この場合、8bitクリーンに処理される必要があります。

binaryは符号化されていないデータであることを示します。 binaryである場合、8bitと異なりテキストとして解釈しようとしません。 これらは主にメール全体の符号化方式として使用されます。

ヘッダの国際化

符号化方式はMIMEヘッダに記載されるため、ヘッダは7bitで記載する必要があります。

そのため、ヘッダを次のような書式で符号化することができます。

=?文字エンコーディング?符号化方式?符号化文字列?=

文字エンコーディングにはcharsetと同じ値を使用します。例えばiso-2022-jp, Shift_JIS, UTF-8です。これはIANA CHARACTER SETSにかかれているものです。

符号化方式にはBase64を使用するBと、quoted-printableの亜種であるQがあります。

たとえばUTF-8の「みぃみるよこはま」を符号化すると以下の文字列が得られます。

=?UTF-8?B?44G/44GD44G/44KL44KI44GT44Gv44G+?=

JISエンコーディングでは次のようになります。

=?iso-2022-jp?B?GyRCJF8kIyRfJGskaCQzJE8kXhsoQgo=

そのヘッダの利点は、従来の7ビットeメールをそのまま書くことができるということです。 あるいは、符号化を行わずに8ビットメールを送信した場合でも、優れたメールクライアントであれば適切にテキストの符号化を理解し、表示できると考えられます。

文字エンコーディングに関する実際

「日本語eメールはiso-2022-jpで送信する」という暗黙の了解があります。

これはMIMEが普及する以前にiso-2022-jpを使用すると決め打ちすることで日本語メールを扱えるようにしたためです。iso-2022-jpを使用するのは、最初に定義された日本語エンコーディングであるからということもありますが、7bitでの取り扱いが比較的安全なため9です。

しかし、この頃から混沌がはじまりました。

iso-2022-jpを使用する以前にはJIS X0201が使用されていました。 このため、「メールで使える文字は半角カタカナ」という時代がしばらくつづいた後に、 逆に半角カタカナが8ビット文字となるために「半角カタカナを使うと文字化けする」という時代がやってきます。

さらにMMS(キャリアメール, ケータイメール)では暗黙にShift JISを使い、Shift JISの外字に絵文字を割り当てるという方法をとったことも混乱に拍車をかけました。10

そして文字化けの原因となることとして次のようなことが多発しました。

作成されたメール側の問題

受け取ったメールクライアントの問題

特にOutlook ExpressがMIMEエンコーディングや文字符号化方式に対する取り扱いがぼろぼろだったことが問題を加速させました。 そして、積極的にUTF-8によるメールを受け入れることを前提とした西ヨーロッパ勢との間に断絶が生じ、やりとりに支障が生じています。

現在新しいフォーマット11がUTF-8を前提としているのは、このようなメールとウェブの文字エンコーディング問題から得た教訓と言えます。

PGP

概要

PGPはメールの暗号化ソフトウェアです。

非対称暗号方式を採用されており、公開鍵と秘密鍵のペアを使用します。 基本的な原理と機能は次のようになっています。

公開鍵は文字通り公開・配布可能な鍵です。 第三者はこの公開鍵を使用し、本人は秘密鍵を使用します。

PGPは強力な暗号を提供します。 1991年の開発当初、アメリカ政府は暗号を武器とみなし輸出を禁止していたため、アメリカ国外でPGPを入手することができませんでした。 開発者のPhilip R. Zimmermann Jr.氏は政府は出版物を取り締まれないことを逆手にとり、pgpのソースコードを書籍として発行し、輸出することで合法的に国外に国外に拡散しました。そして、有志によりこれに基づいてアメリカ国外で制作されたPGP国際版が公開されました。

1999年末にアメリカ政府がPGPの輸出を一部国家を除いて認めたため、アメリカ国外でも合法的にオリジナル版PGPの入手・使用が可能になり、これに伴って国際版の開発は終了しました。

紆余曲折を経て現在PGPはシマンテックに買収されています。

PGPの仕様はRFC1991/2440/4880/5581/6637として公開されています。 また、eメールを暗号化するPGP/MIMEのフォーマットはRFC2015/3156として標準化されています。

この仕様がOpenPGPと呼ばれます。

GnuPGはOpenPGP(RFC4880)に基づいたGNUによるPGPの別実装です。1999年にリリースされました。 フリーであることを重視し、PGPとの完全な互換性はありませんが、現在はこちらのほうが多く使われており、Linuxでは標準的なツールのひとつとなっています。

GnuPGの利用方法

鍵を生成する

GnuPGのデフォルトの設定ファイルは~/.gnupg以下にあります。 GnuPGディレクトリは安全性のため、オーナのみがアクセスできる状態でなくてはいけません。

鍵ペアを生成するには

gpg --full-gen-key

とします。 通常RSAが使われ、サポートしているcipherは--versionによって確認することができます。

gpg (GnuPG) 2.2.4
libgcrypt 1.8.2
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Home: /home/aki/.gnupg
サポートしているアルゴリズム:
公開鍵: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
暗号方式: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256,
      TWOFISH, CAMELLIA128, CAMELLIA192, CAMELLIA256
ハッシュ: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
圧縮: 無圧縮, ZIP, ZLIB, BZIP2

対象鍵での暗号化

対象暗号によってファイルを暗号化することができます。

gpg -c <file>

標準入力から受け取った内容を暗号化することもできます。

公開鍵での暗号化

-eまたは--encryptオプションによってファイルを公開鍵で暗号化することができます。

宛先となる公開鍵は-rオプションによって指定します。メールアドレスやIDを使用することができます。

gpg -r info@mimir.yokohama -e <file>

--armorオプションを使うとコピー&ペーストに適した形式で出力します。 --armorを使用しない場合、出力されるデータはバイナリです。

公開鍵を配布する

次の形式でコピー&ペースト可能な公開鍵を出力します。

gpg --armor --export <userid>

鍵ファイルをインポートするには次のようにします。

gpg --import <keyfile>

またはPGP鍵サーバーに登録することで直接連絡せずとも公開鍵を入手できるようになります。

gpg --send-keys <keyid>

鍵サーバーから入手するには次のようにします。

gpg --recv-keys <keyid>

例えば次のようにしてinfo@mimir.yokohamaの鍵の入手することができます。

gpg --recv-keys 1441B6AC6735D591B03C0A024977B28DAB84D93A

ただし、鍵を登録することは誰にでもできます。本人確認プロセスはありません。 本人確認するには本人だと確認できる情報源が発信している鍵の指紋情報などと照合する必要があります12

eメールでGnuPGを使用する

PGP/MIMEによって暗号化メールや署名を使用することができます。

ただし、対応していない環境では添付ファイルに見えるほか、署名/暗号化メールを無条件にスパムとして判定するサーバーもあるようですので、その利用には注意が必要です。

利用条件

メールクライアント環境使用条件
Mozilla ThunderbirdWin / Mac / UnixEnigmail プラグインを使用する
SylpheedUnix / Win最新版は標準サポート
Clas MailUnix標準プラグインによるサポート
KmailUnix標準サポート
EvolutionUnix標準サポート
MewUnix-Emacs標準サポート
MuttUnix設定による
Outlook ExpressWinPGP提供のプラグイン
OutlookWinPGP提供のプラグイン
Windows Live MailWinPGP提供のプラグイン
Windows MailWin10サポートしない
Apple MailMacGPG Toolsによるサポート
K-9 MailAndroidAPGによってサポート

メール暗号化のヒント

PGP Inline

メール本文内にASCII Armor形式の記述を使用行う方法があります。

署名に対応していない環境でも問題なく取り扱うことができるという意味ではメリットがありますが、 古い形式とされ、順次廃止されています。

S/MIME

S/MIMEはPGP同様にeメールの暗号化と署名を署名行うことができます。

暗号化にはSSL証明書を使用し、鍵自体によって本人確認を行うことができます。 ただし、SSL証明書一般の問題として、証明書を認証局によって証明してもらう必要があり、コストが高くあまり普及していません。

また、S/MIMEはPGP/MIMEと比べ同様の問題に加えて次のような問題があります。

例えば三菱東京UFJ銀行は送信するメールをS/MIMEによって署名しています。

参考文献

O’Rerilly Japanによる電子メールプロトコル: 基本・実装・運用がGoogle bookによって公開されています。


  1. UUCPはネットワーク・プロトコルです。インターネットではこれとは異なるIPが使われています。

  2. RFC2554によって規定されています。

  3. MSAはメールヘッダを読み書きします。

  4. 今回この内容を執筆するために検索したところ、「記号は使えない」という方向性の誤った情報がほとんどという事態に遭遇しました。サービス提供側でもそのような認識のためにRFCに準拠した正しいメールアドレスを拒否するサービスがかなり多数あります。なお、 http://orgachem.hatenablog.com/entry/2013/11/26/015343 にその問題への言及があります。

  5. 現在は携帯電話キャリアはこのようなRFC違反メールアドレスの発行を停止しています。

  6. RFC的には携帯電話でよくあった.の使い方について、ダブルクォートで囲んた背quoted-string形式にすることでRFC準拠にすることはできますが、それをソフトウェアが正しく扱うことを期待するのは困難です。なお、quoted-stringの使用自体がRFCにおいても「非推奨」です。

  7. ときどき「POP3の次のプロトコルだからIMAP4」という記述をみかけますが、IMAP3, IMAP2などもあります。IMAP2はTCP/143を使用しますが、IMAP3はTCP/220でした。

  8. メールあるいはメールデーモンが特別な意味として理解する可能性のある文字、例えば.などのことです。

  9. ISO-2022-JPを「7bitで符号化する」と説明しているものをよく見かけますが、そんなことはありません。最上位ビットをGL/GR領域の区別に使用します。

  10. WILLCOMのPHSであるLIBERIOでは2015年8月のアップデートで突然メールクライアントがShift JISからUTF-8に切り替わり、送受信は暗黙にUTF-8を使用するようになりました。

  11. 例えばXML, YAML, JSON, Markdown, ReSTなどです。

  12. 2020-01-22まで有効なinfo@mimir.yokohamaのGnuPG鍵1441B6AC6735D591B03C0A024977B28DAB84D93Aの指紋は1441 B6AC 6735 D591 B03C 0A02 4977 B28D AB84 D93Aです。