今年最初の調査として、電子メールの解析していました。
オープンなものなので、解析と言うよりは勉強という感じですが。何しろ知識自体は数年前のものだったので、今回調べ直してみて新しい発見がいっぱいでした。
ここでは、その自分的新発見について記録しておきたいと思います。
配送情報と表示情報は実は違う
当たり前と言えば当たり前のことですが、SMTPサーバがデータの配送に使う情報と、電子メールクライアントで表示するときの宛先情報が異なるということを改めて知りました。
SMTPサーバーが参照する部分は エンベロープのヘッダ部分で、電子メールクライアントが参照して表示に使っている部分はエンベロープが持っている中身のデータのうちのメールヘッダと呼ばれる部分でした。
telnet使って、mail from や rcpt to でアドレス入力した覚えが確かにあります。これって配送用の情報だったのかと今更納得しました。
メール本文はJIS ・・・ではない
メール自身は7bitで送る必要があるためJIS(ISO-2022-JP)に変換して送らないと駄目だと考えていました。
しかし実際のところは、Content-Transfer-Encodingで 8bitを指定できたりして、Shift-JISをそのまま送ってしまうケースもあるみたいです。
また、本文自体をBASE64エンコードしてしまって、Content-Transfer-Encoding: base64 として送ってしまえたりするみたいです。
この自由度が上がった感じはすごいなと思います。知識の古さを実感してしまいました。
メールの件名も JISではない
メールヘッダの部分でも必要に応じてエンコードできるため、文字コードJISに縛られる必要はないみたいです。
=?UTF-8?B?44GK?= などというように =? ?= ではさんで好きな日本語でいけるようです。
さらには、このデータバイナリ部分はBASE64というきまりでもなく、Qエンコード(Quoted-printable)もサポートしています。
データを取り出すにはバイナリ部分をデコード して純バイナリデータ列を取得します。この際、真ん中のエンコード種別で Qエンコードなのか BASE64なのかを判定できます。この後得られたデータは先頭の文字の符号化が何であるかの識別に従ってデコードすれば、目的とする文字列が復元できます。
うまくできてるなぁと思いました。
コメント