今日は、電子メールの誕生日(1982)
誕生日って言っちゃうと、少し語弊があるかも。
正確に言えば、インターネットの電子メールの送信方式である、SMTP の最初のバージョンを定めた仕様書である、RFC822 の公開された日ですね。
電子メール自体は SMTP 以前から存在していて、いわゆる「パソコン通信」だってあったし、インターネットでも RFC561 で定めています。
ただ、RFC561 では、メールヘッダの書き方だけ定めていて、「FTP で相手のサーバーに送る」となっているのね。
特定のディレクトリに送り込みさえすれば、あとは定められた形式で書かれているヘッダを読んで、各自のディレクトリに配送できたのでしょう。
ヘッダの書き方はこの後何度か改定されますが、送り方は FTP のまま。
FTP と言うことは、自分のアカウントが使える範囲でしかメールが送れない、ということです。
まぁ、単純に言って「学内の友達にはメールが送れる」とかですね。
工夫次第で学外にも送れそうだけど、どこの相手にでも自由自在、とはいかない感じ。
これが、メール専用のプロトコルが定められ、今知られているような「電子メール」が出来上がったのが、RFC822 です。
RFC には公開日が記されるので、1982年の今日公開された、と言うことがわかります。
時々僕の日記などに顔を出す RFC っていうのは、Request For Comments の略ね。
本来は「コメント募集」って意味で、技術仕様ではありませんでした。
インターネットの最初期において、複数の違うマシンを接続するときに情報を整理するのに考えられた方式です。
誰かが「Request For Comments」と書かれた大学ノートに、自分が考えた技術アイディアをメモします。
もしかしたら、それは考えた人のコンピューターではうまくいくけど、別のコンピューターではダメな方式かもしれない。
ほかの人から見て、そうした、発案者が気づかなかった部分にコメントが欲しいわけです。
で、コメントを出す方も一緒になって解決策を考え、皆が参照する「技術仕様」の位置づけになっていきます。
今では、この議論を RFC 上でやるのは混乱するため、Internet-Drafts という文書を発行して意見を募り、十分に議論してから RFC の番号を割り当てるようになっています。
じゃぁ、RFC はもう RFC じゃないじゃん、って思うけど、慣習的に名前だけ残っているのです。
さて、話を戻して RFC822 。
これは、SMTP の送信形式だけでなく、それ以前に定められた「メールヘッダ形式」などもすべて含め、電子メールとしての基本的な仕様を網羅できる文書になっています。
とはいえ、すでに時代遅れ。
RFC2822, RFC5321 & 5322 などで更新されています。
2822 は 822 の更新だけど、さらに更新する際には肥大化しすぎたし、メールのフォーマット形式はその後 HTTP 等にも流用されるようになっていました。
そのため、SMTP を再定義したのが 5321 で、メッセージフォーマットを再定義したのが 5322 と分離されたのです。
内容に関しては、現在みんなが「あたりまえ」と思っていることが書かれているので、特に言うべきことは無いです。技術者でなければ特に読む必要なし。
しかし、「あたりまえ」というのはここに規定されているから当り前なのであって、重要であることは間違いありません。
技術者や、そうでなくてもちょっと読んでみたい人のために…
たとえば、数年前まで問題になっていた、DoCoMo の i-mode メール。
i-mode メールでは、メールアドレスの @ の左側で、. （ピリオド）が自由に使えました。
でも、RFC5322 には、こう書かれています。
atext = ALPHA / DIGIT / ; Printable US-ASCII
"!" / "#" / ; characters not including
"$" / "%" / ; specials. Used for atoms.
"&" / "'" /
"*" / "+" /
"-" / "/" /
"=" / "?" /
"^" / "_" /
"`" / "{" /
"|" / "}" /
dot-atom-text = 1*atext *("." 1*atext)
dot-atom = [CFWS] dot-atom-text [CFWS]
local-part = dot-atom / quoted-string / obs-local-part
addr-spec = local-part "@" domain
…あぁ、ややこしい！
RFC は技術文書なので、BNF という特殊な記法で（間違いが無いよう厳密に）書かれているのです。
BNF は、= の左側に書かれている「名前」は、右側に書かれている「意味」だよ、という定義方法だと思ってください。
等式に見えるけど、定義ね。数学みたいに「これとこれは同じです」ではなく、「今こう決めました」なので、意味がわからなくても難しがる必要はないです。
でも、知らない名前が書かれていたら、どこかでその名前について定義しているはずだから、ファイルの中を検索して探しながら読む必要がある。
ちなみに、英単語みたいに書かれているのが「名前」で、" " で囲まれているのは「文字」です。
上の方に ALPHA と書かれているのは、アルファベットの文字、と言う意味の名前なのだけど、"!" と書かれているのは ! という文字。
さて、先の定義、上から読もうと思っても混乱します。一番下から見てください。
addr-spec というのは、「メールアドレス」として書ける文字列のこと。これを「local-part と domain の間に、 @ を挟んだもの」と定義しています。
これならわかる気がする？
じゃぁ、local-part ってどんななの？ と言うのがその上の行。dot-atom か、 quoted-string か obs-local-part のどれかを選んでよい、と言う意味です。
dot-atom というのは、[CFWS] が前後についた、dot-atom-text 。
[CFWS] っていうのはまた別に定義があるのだけど、Comment & Folding white space の略。
「コメントと、改行・スペース・タブ」の意味で、これらの「無意味なもの」がついてもいいですよ、となっている。
[ ] で括られているのは「なくてもよい」と言う意味なので、必ず付く必要はないです。
…ということは、メールアドレスを書くときは、@ の前にスペースを置いても同じ意味になる、と言うことです。普通そんな書き方しないけど、もしその書き方で送れないメールソフトがあったら RFC に従っていない、と言うことになります。
dot-atom-text は、１つ以上の atext の連続の後に、. （ピリオド）を置いて、また１つ以上の atext を置く、と言うのを任意回繰り返してよい形式。
1* というのは、「その後ろにあるものが、１回以上繰り返される」の意味で、 * だけだと「０回以上繰り返される」です。
先に書いた通り、「なくてもよい」は [ ] なので、*a と [1*a] は同じ意味になりますね。
次でやっと最後。atext というのは、「英文字と数字と、ここに示された記号」のうち、任意の１文字です。
長々と書きましたが、言葉で厳密に説明すると長くなるものを、BNF では簡潔に書けているわけです。
読み方を知っておくと、いろいろと発見があるかも。
たとえば、atext を眺めただけでも、メールアドレスに ? や ! を含んでも良い、と言うことがわかります。
これは、「含んでも良い」であり、「使える」ではないことに注意。
使えるかどうかは、自分がメールボックスを持っているシステムの仕様によります。
たとえば、unix ではアカウントに - （ハイフン）は使えなくて、local-part は普通アカウントが使用されます。つまり、local-part にはハイフンは使えないことになります。
…が、unix のプログラムである qmail は、ハイフンが入っていると「その前までをアカウント」だと認識して、該当アカウントを持つユーザーにメールを配送します。
このため、ユーザーは目的に応じてメールアドレスを変更でき、目的別のメールの振り分けなどが楽に行えます。
また別の話ですが、「自分のシステム」が local-part に記号を使えないからと言って、どんなシステムでも使えない、と決めつけるのは間違いです。
多くの WEB サービスで、メールアドレスを ID としてログインできるような形になっていますが、loca-part 部に ? 等の記号が入ると、不正なアドレスだとエラーになるものもあるようです。
RFC で認められている文字なのだから、これがエラーになるのはおかしいです。
自分が勝手に考える「常識」の前に、技術仕様としてどう定義されているのか確認しましょう、という、技術者なら当然の話。
でも、BNF の読み方を知らない技術者は（残念ながら）非常に多いのです。
さて、話を戻しましょう。
dot-atom-text をもう一度簡単に示せば、「atext を連続させる際、途中でピリオドを挟んでもよい」と言う形式です。
atext の連続は許されますが、ピリオドの連続は許されません。
「途中」ではない、先頭や末尾のピリオドも許されません。
i-mode メールが一時期問題視されていたのは、これが許可されてしまっていたため。
au は RFC に従っていたのですが、i-mode の普及に伴って「i-mode に仕様をあわせる」という意味不明の改悪をして、大騒ぎになりました。
ただね、当時一部のメールサーバーで i-mode からのメールを受け取れないので問題視されて「docomo は RFC に違反している」と言われていたのだけど、受け取れないメールサーバーだって RFC 違反。
RFC では、常に「自分が作るデータは厳密に。しかし、相手から送られてくるデータには寛容に」が求められています。
だから、RFC に違反するデータを作り出す i-mode メールが問題なのは当然なのだけど、そのデータを寛容に受け取れないメールサーバーにも問題があるのです。
実際、多くのメールサーバーではちゃんと受取れていたしね。
RFC っていうのは、「そのデータしか送られてこない」と保証する類の仕様書ではなくて、「相手はともかく自分は」従いましょう、という緩い決まりごとにすぎません。
電子メールの誕生日って話から離れてしまいますが、せっかく RFC の話をしたので…
RFCには「ジョーク RFC」と呼ばれるものがあって、これは４月１日に発行されます。
最近では恒例になりすぎて、「ジョークを書いてやろう」と力が入りすぎているのが多くてちょっと興ざめなのだけど。
でも、これらのジョークは、技術文書のふりをして書かれているので、BNF を読めると面白さが広がることも多いです。
（ジョークだから、BNF 使わないものも多いのだけど）
初期(1978)に書かれた RFC748 とか、なかなか名作。
一ひねりしてあって、裏読みしないと真意がわかりません。
（真意がわかると、これがジョークではなく「切望」であると、技術者なら共感できるはず）
RFC1149 も名作とされているのですが、日本語訳はどうもまずいものばかり。（日本語訳は、探せば見つかります）
これは英語の言葉遊びをうまく織り交ぜていながら、バカバカしいことを真面目に技術的に書いているから「名作」なのです。だから、日本語にすると面白さが失われてしまう。
RFC3514も名作。技術的に確かに可能だけど「作っても意味ない」と明らかにわかるものを大真面目に書いた…というものだったのですが、当日中に（つまり、エイプリルフールジョークとして）本当に作る人が現れて話題になりました。
まぁ、「ジョーク RFC」で探せば紹介しているサイトは一杯あるので、興味あったら探してみてね。
（本も出版されているけど、あまりお勧めしない）
同じテーマの日記(最近の一覧)
関連ページ
別年同日の日記
申し訳ありませんが、現在意見投稿をできない状態にしています。 |