そのデータが、決められたルールと指示にしたがって移動(コピー)される、つ まり、いろいろなプログラムを通じて、ある時は(有線・無線を問わず)ネット ワーク上を流れたり、ファイルとしてコンピュータの中にたまってたりしている、 ということです。
この「データがバケツリレーのように転々と移され(流れて)
どこかに溜る」というイメージをまずは是非もってください。
電子メールの配送の仕組み
上の図は、簡略化されたメール配送フローの仕組みです。たとえば、左のPC (パソコン)のユーザが、右のPCのユーザーにメールを送ることを考えてみま す。
ここでは、インターネットでメールをやりとりするコンピュータ(サーバ)は、 誰かどこかでが事前に設定していることで、メールの交換が出来る、というこ とを確認してください。
ここで大切なことは、受取人とかを実際に決めているのは、ヘッダではな くエンベロープである、ということです。実際From: や To: には、フォー マットにしたがってる限り架空のアドレスでもなんでも書けます。メーリング リストなどはこれを利用してるメールの流れを制御しています。
但し、近年は迷惑メール対策が厳しくなっいてて、あまり自由に書き換えると 迷惑メールと判定されることもあるので注意が必要です(後述)
telnet [serverのホスト名] smtpとすることで試せます。例えば私が自分あてにメールを出す場合、以下のよう になります。 赤字が人(私)の入力した ところで、 緑はサーバが返して来たメッセージ、 青はコメントです。
$ telnet ma.e-chan.jp 25 Trying 52.37.234.165... Connected to ma.e-chan.jp. Escape character is '^]'. 220 ma.e-chan.jp ESMTP helo hannan-u.ac.jp 挨拶(?) 250 ma.e-chan.jp mail from:<maechan@hannan-u.ac.jp> エンベロープその1=送り主 250 2.1.0 Ok rcpt to:<m@e-chan.jp> エンベロープその2 =宛先(最重要! 250 2.1.5 Ok data 今からデータです、という意味 354 End data with <CR><LF>.<CR><LF> From: maechan@hannan-u.ac.jp ヘッダを打ち込む。ヘッダのフィールドの頭文字は必ず大文字で To: m@e-chan.jp 「:」(コロン)のあとの空白も忘れずに Subject: test via SMTP This is a test. Please ignore?! 空行はヘッダとボディの切れ目!その後でボディを打ち込む。 . 最後は「.」(ピリオド)だけの行 250 2.0.0 Ok: queued as 4397760FC8 quit 対話の終わり 221 2.0.0 Bye Connection closed by foreign host.
今では想像しにくいかもしれませんが、メールは原則文字だけで、それも最大 50kb (5万バイト)にする、というのが1980年代の常識でした…(今は昔)
この方式は、データのほとんどが ASCII だけど、一部 ASCII ではない文字 (ヨーロッパ大陸の、アクセントとかが付いた文字等)がある場合、その文字 だけを q-encoding すると、非対応のソフトウェアでもおおまかなところは把 握できる、という利点があるので、よく利用されます。
画像などのバイナリファイルはもっぱらこちら (base64) でやりとりされます。
データ | 文字 | データ | 文字 | データ | 文字 | データ | 文字 | |||||||
0 | 000000 | A | 16 | 010000 | Q | 32 | 100000 | g | 48 | 110000 | w | |||
1 | 000001 | B | 17 | 010001 | R | 33 | 100001 | h | 49 | 110001 | x | |||
2 | 000010 | C | 18 | 010010 | S | 34 | 100010 | i | 50 | 110010 | y | |||
3 | 000011 | D | 19 | 010011 | T | 35 | 100011 | j | 51 | 110011 | z | |||
4 | 000100 | E | 20 | 010100 | U | 36 | 100100 | k | 52 | 110100 | 0 | |||
5 | 000101 | F | 21 | 010101 | V | 37 | 100101 | l | 53 | 110101 | 1 | |||
6 | 000110 | G | 22 | 010110 | W | 38 | 100110 | m | 54 | 110110 | 2 | |||
7 | 000111 | H | 23 | 010111 | X | 39 | 100111 | n | 55 | 110111 | 3 | |||
8 | 001000 | I | 24 | 011000 | Y | 40 | 101000 | o | 56 | 111000 | 4 | |||
9 | 001001 | J | 25 | 011001 | Z | 41 | 101001 | p | 57 | 111001 | 5 | |||
10 | 001010 | K | 26 | 011010 | a | 42 | 101010 | q | 58 | 111010 | 6 | |||
11 | 001011 | L | 27 | 011011 | b | 43 | 101011 | r | 59 | 111011 | 7 | |||
12 | 001100 | M | 28 | 011100 | c | 44 | 101100 | s | 60 | 111100 | 8 | |||
13 | 001101 | N | 29 | 011101 | d | 45 | 101101 | t | 61 | 111101 | 9 | |||
14 | 001110 | O | 30 | 011110 | e | 46 | 101110 | u | 62 | 111110 | + | |||
15 | 001111 | P | 31 | 011111 | f | 47 | 101111 | v | 63 | 111111 | / |
ちなみに、もとのデータのバイト数が3の倍数ではない場合はちゃんと変換でき ないので bit '0' を追加して 6 bit づつになるようにして、さらに 4 文字ず つ変換した時に 4 文字に足らない場合は '=' を追加することになってます。例えば "ABC" という ASCII 文字列を Base64 変換す ることを考えると、ビット表現すると
01000001 01000010 01000011であり、これを6ビットずつ分解すると010000 010100 001001 000011となるので、これを上の変換表にあてはめることにより、 "QUJD" となります。ちなみに "AB" だけなら "QUI=" で、"A" だけなら "QQ==" です(確認してみてください)
Content-Type: text/plain; charset=ISO-2022-JPと書けば、本文はISO-2022-JP = いわゆる 7bit JISコードでかかれ た 文(単なる文字の列)だ、ということがわかるわけです。メール のヘッダと本文もこの枠組の特殊形と考えてよいです。
Content-Type: multipart/mixed; boundary="hogehoge"というのを使うと、hogehoge というのを boundary=切れ目として使うことで、 multipart = マルチ(複数)のパート(部分)、すなわち メールの中に構造を作ることが出来ます。我々がメールで添付ファイル形式で いろんなデータを送る事ができるのは、この仕組みのおかげです。
ちなみに、切れ目は以下のように(BNF表現で)規定されていますboundary := 0*69 つまり、(最後に)最低1つの空白でない文字を含む、最長70文字の文字列 (英数字と、上で規定されている記号)です。bcharsnospace bchars := bcharsnospace / " " bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" / "+" /"_" / "," / "-" / "." / "/" / ":" / "=" / "?"
以下は、マルチパートの例として、画像を添付したメールです(一部不要なヘッ ダを切り取ってます)。
Return-Path: <maechan@hannan-u.ac.jp> Date: Wed, 29 Oct 2003 17:18:12 +0900 (JST) Message-Id: <20031029.171812.32173164.maechan@hannan-u.ac.jp> To: maechan@ieee.org Subject: attached image sample From: Toshiyuki MAEDA <maechan@hannan-u.ac.jp> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.1 MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Oct_29_17:18:12_2003_783)--" Content-Transfer-Encoding: 7bit X-UIDL: 8+6"!99""!?Bk!!bjp"! ----Next_Part(Wed_Oct_29_17:18:12_2003_783)-- Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit 添付画像のサンプルです。 ----Next_Part(Wed_Oct_29_17:18:12_2003_783)-- Content-Type: Image/Gif Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="dum.gif" R0lGODdhOwA2AIAAAAAAAP///ywAAAAAOwA2AAACtIyPqcvg/5icVMKLq94H+8yFy0dC4hmUqolq 6+u0FEzLFv3aIw7rCI/zGYA1HzGoOxZtyh6z6WxBo6hpTmZdPbOkLdfj/V7C4gi2jE4DUmQx+6x+ w8vDZLpud+Pz2Z9Qv8cHlbAmlDKlUGh4SNSw2NE48vjjpEg4mfhxKYl5YunXKfLZESrqWMoxGog6 c8paoSr3OhEbOwuaeNvKqeu62cv7CyyMO1x8bCyLbFybTAyphqRQAAA7 ----Next_Part(Wed_Oct_29_17:18:12_2003_783)----
また次は、マルチパートの別の有用な例である、PGP 署名したメールです(一 部不要なヘッダを切り取ってます)。
Return-Path: <maechan@hannan-u.ac.jp> Date: Wed, 29 Oct 2003 17:11:28 +0900 (JST) Message-Id: <20031029.171128.119854785.maechan@hannan-u.ac.jp> To: maechan@ieee.org Subject: PGP signature sample From: Toshiyuki MAEDA <maechan@hannan-u.ac.jp> X-Mailer: Mew version 3.2 on Emacs 20.7 / Mule 4.1 MIME-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_Oct_29_17:11:28_2003_659)--" Content-Transfer-Encoding: 7bit X-UIDL: E\A"!om)!!:VJ"!QBQ!! ----Security_Multipart(Wed_Oct_29_17:11:28_2003_659)-- Content-Type: Text/Plain; charset=iso-2022-jp Content-Transfer-Encoding: 7bit PGP の署名の例です。 ----Security_Multipart(Wed_Oct_29_17:11:28_2003_659)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQA/n3Y5R1DOJaOzii0RAh+9AJ9ZLBwyqzzPcFx7CLwaL4QJRhcQJgCfb5SG NuGDQzmivytG8nv7HTC/VNg= =utS/ -----END PGP SIGNATURE----- ----Security_Multipart(Wed_Oct_29_17:11:28_2003_659)----
本講座の小テスト・課題提出システム lect@e-chan.jp もそうですし、他にも 例えば、「XXXX site」「Get Viagra!」「未承諾広告」のような、読みたくも 無いメールを自動的に捨てるとか、"From:" が music-store-news@amazon.co.jp だったらこれは広告なのでとりあえず置いて おくが、転送はしない、などのことが、比較的簡単なプログラムによって実現 できます。
もちろん、本格的に SPAM のフィルタリングをしようとすると、 込み入った処理が必要になります。興味ある人は、 スパムへの対策 ---A Plan for Spam 等を読んでみてください。さらに言 うと、近年では Deep Learningによる振分けも行われていると思われます。以下はその一例(拙作)で、メールサーバ上のホームディレクトリ直下の .forward という名前のファイルに、
"|/home/maechan/bin/sel-forw /home/maechan/lib/flist maesub"として指定しているプログラムです。指示は "" で囲み、"|" (縦棒?パイプの 意味)は次に指定されてるのがプログラムであり、そのプログラムの標準入力へ データが流れていく、という印です。
多くの UNIX 系のサーバでは、各ユーザのホームディレクトリ に .forward というファイルをつくっておくと、スプールする時にこ のファイルをチェックして、その指示にしたがいます。.forward では転送先の アドレスを書くことでそのサーバからさらに別のところにメールを転送させた り、プログラムを指定することで、そのプログラムにメールを読みこませて処 理させることが出来ます。説明は…略させてもらいますので、perl の勉強がてら読んでみてください (?!)