戯術者の日記

サーバの応答

hmiyazaki@MOZZARELLA:~$ telnet cheddar 110
Trying 192.168.1.1...
Connected to cheddar.
Escape character is '^]'.
+OK Qpopper (version 4.0.5) at cheddar starting.  <23361.1121585637@cheddar>

に対して、<23361.1121585637@cheddar> がチャレンジ。

で、ユーザ名が zaki, パスワードが passwd だとすると、必要なダイジェストは

<23361.1121585637@cheddar>passwd

の MD5 ハッシュ値となる。
この場合は

hmiyazaki@MOZZARELLA:~$ printf '<23361.1121585637@cheddar>passwd' | md5sum
98296f29bfa38c2a22cf886222956b6f *-

みたいな感じで。

んで、サーバへのリクエストは

APOP zaki 98296f29bfa38c2a22cf886222956b6f

で認証する。

Post Office Protocol - Version 3(RFC1939 日本語訳)

APOP命令を実装するPOP3サーバーは、その挨拶にタイムスタンプを含む。タイムスタンプの文法は[RFC822]の'msg-id'に相当し、 POP3サーバーが挨拶を発行する度に異ならなければならない(MUST)。例えば、POP3サーバーのインスタンス毎に別々のUNIXプロセスが使用されるUNIX実装において、タイムスタンプの文法は以下のようなもので良い。

    <process-ID.clock@hostname>

ここで'process-ID'はプロセスのPIDの10進値であり、clockはシステムクロックの10進値、hostnameはPOP3サーバーを実行中のホストに対応するFQDN（fully-qualified domain-name）である。

POP3クライアントはこのタイムスタンプに注目し、APOP命令を発行する。パラメータ'name'は、USER命令の'name'パラメータと同じ意味を持つ。パラメータ'digest'は、タイムスタンプ（鍵括弧を含む）の直後に共有されている秘密を付加した文字列に、MD5アルゴリズム [RFC1321]を適用して計算される。この共有されている秘密は、POP3クライアントとサーバーのみが知っている文字列である。その秘密の情報は、誰でもその名前のユーザーへのなりすましを許してしまう事になる為、認証されない公開を防ぐように十分な注意が必要である。'digest'パラメータ自身は、小文字のASCII文字を使った16進形式で送信される16オクテットの値である。

メモ程度で実装じゃないけど^^;
CRAM-MD5 認証については、ぺるりめものダイジェスト2 cram-md5認証 (module)Digest-HMAC_MD5参照。

PLAIN 認証は

AUTH PLAIN base64-encoded-username-and-passwd

と、AUTH コマンドの引数に、"PLAIN" と base64 で符号化したユーザ名とパスワードを与える。
符号化の法則は

username\0username\0password

まぁ、こんな感じで。\0 は 0x00 のヌル文字。

% printf 'username\0username\0password' | mmencode

LOGIN 認証はもっと簡単に(<<はリクエスト、>>はレスポンス)

<<AUTH LOGIN
>>334 VXNlcm5hbWU6
<<VXNlcm5hbWU6
>>334 UGFzc3dvcmQ6
<<UGFzc3dvcmQ6

と、POP3 と似たような感じで、ユーザ名とパスワードを単に base64 エンコードしたデータを渡す。
ちなみに、"VXNlcm5hbWU6" は "Username: " を、"UGFzc3dvcmQ6" は "Password: " をエンコードしているだけ。

ぺるりめものダイジェスト2 cram-md5認証 (module)Digest-HMAC_MD5であまり良くわからず書いていたが、ちょっと確認。
HMAC メッセージ認証のための鍵付ハッシング(RFC2104 日本語訳) かな。

とりあえず…

以下のように 2 つの異なる固定文字列 ipad と opad を定義する (その 'i' と 'o' は、inner と outer を連想させるように付けてある):

ipad = バイト値 0x36 を 64 回繰り返した文字列
opad = バイト値 0x5C を 64 回繰り返した文字列

は、固定で用意ぽいな。ちなみに 0x36 は "6" で、0x5C は "\" だ。

でもって、

データ `text' に対して HMAC を計算するためには、以下のようにする。

H(K XOR opad, H(K XOR ipad, text))

すなわち、

   1. B バイトの文字列を作るように K の終わりまでゼロを追加する
   2. （例えば、K が 20 バイトの長さで B=64 であるならば、K に 44 個のゼロのバイト値 0x00 が追加される） ステップ (1) で計算された B バイトの文字列と ipad との XOR（ビット毎の排他的論理和）を計算する。
   3. ステップ (2) の結果生じた B バイトの文字列に、データ `text' のストリームを追加する。
   4. ステップ (3) で生成されたストリームに H を適用する。
   5. ステップ (1) で計算された B バイトの文字列と opad との XOR（ビット毎の排他的論理和）を計算する。
   6. ステップ (5) の結果生じた B バイトの文字列に、ステップ (4) の H の結果を追加する。
   7. ステップ (6) で生成されたストリームに H を適用し、その結果を出力する。

自分の言葉で極簡単にまとめると、
1. パスと 0x36 の XOR にデータをくっつけたものの MD5 ハッシュを取得。
2. パスと 0x5C の XOR に↑をくっつけたものの MD5 ハッシュを取得。
3. ↑が結果
ということか。な?

本文文字数が192文字以内以外に、各ヘッダの文字数にも依存するみたい。件名だけはある程度の長さ以上(忘れた)だとスーパーメールになるのは知ってたけど。

http://developers.vodafone.jp/dp/tech_svc/mail/

http://developers.vodafone.jp/dp/faq/faq.php#20_11

Q11: パソコンから添付ファイル付きのEメールをボーダフォン携帯電話に送信した場合、ボーダフォン携帯電話側で通知できない添付ファイルがあるのですが?
A11: ボーダフォンの仕様では、「Content-Typeのnameパラメータ」で添付ファイルを判断しています。「Content-Dispositionのnameパラメータ」では添付ファイルを判断していませんので、ご注意下さい。

あ、そうなんだ…。
ところで、Content-Disposition が持つファイル名のパラメタ名は filename だよな^^;