第01回APOPについて
|
|
APOPはPOP3で使用される認証方法で
「APOP userID xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx」という形です。
xxxの部分にはMD5ダイジェストが１６進数で入ります。
まずサーバーが接続時の返信にタイムスタンプ
「<unique-string@hostname.domain>」という形の文字列を含めます。
(サーバーによっては多少異なる場合があります)
もし、この文字列が含まれていないならそのサーバーはAPOPに対応していません。
タイムスタンプとパスワード（ユーザーの）を結合し
（<unique-string@hostname.domain>Password）MD5ダイジェストを求めます。
特徴としては毎回送信する文字列が違うのでリプレイ攻撃を防止するのとネットワーク上にパスワードが流れるのが防止できます。
（MD5はダイジェストから元の文字列を求めることが難しいので）
しかし、管理側には素のパスワードが必要になります。（これは管理上の問題でクライアント側には問題はありません）
|
第02回POP Before SMTPについて
|
|
POP Before SMTPはSMTP向けの認証方法でSMTP AUTH（SMTP認証）が無い時代に考え出されたものです。
動作はまずPOP3サーバーに認証します。次に、サーバーとの接続を切りSMTPサーバーに接続します。
サーバー側がPOP3に認証した段階でクライアントのIPを一定期間保存しておくことで認証の役割を果たします。
SMTPには認証の仕組みがなかったので正規のユーザーでは無いクライアントでも送信できるというバグ（仕様）に対応するために使われています。
逆にこれを用いればプロバイダが異なっていても（通常、プロバイダのメールサーバーは自分のプロバイダ以外からのメール送信要求は受け付けない）
任意のメールサーバーで送信することが可能になります。
「A」というプロバイダに接続していて「B」というプロバイダのメールサーバーで送信できるということは問題です。しかし、SMTP認証を用いれば可能です。
SMTP認証のAUTHコマンドに対応していないサーバーも多数あるので最低でもPOP Before SMTPには対応しているべきです。
|
第03回SMTP認証（PLAIN）について
|
|
AUTH PLAINはSMTPで使用される認証方法で「AUTH PLAIN xxxxxxxxxxxxx」という形です。（AUTH PLAINとxxxxが別々に送信する場合もある）
xxxにはBASE64文字列が入ります。認証に成功すると「235 -----」という文字列が返ります。（---の部分はサーバーごとに異なる）
「userID\0userID\0Password」（\0はバイトの値で０です）という文字列をBase64に変換するだけです。
ただし、場合によっては「\0userID\0Password」になる場合もあります。
人間が見ただけでは元の文字列が何かはすぐにはわかりませんが簡単に元の文字列に戻すことができるのでセキュリティ面では甘いです。
仕様する場合はなるべく通信をセキュリティ化した方が安全です。
また、サーバーが対応していない場合もあります。EHLOでのリプライにAUTHが入っていなかったりPLAINという文字列が入っていない場合は非対応です。
例
c:AUTH PLAIN
s:334
c:YWRtaW4AYWRtaW4AYWRtaW4=
s:235 2.0.0 Authentication successful
このときのユーザーIDとパスワードはそれぞれ「admin」です。
|
第04回SMTP認証（LOGIN）について
|
|
AUTH LOGINはSMTPで使用される認証方法で「
c:AUTH LOGIN\r\n(リターン)
s:334 VXNlcm5hbWU6\r\n(リターン)「Username:」をBase64に変換したものです。
c:xxxxxxx\r\n(リターン)
s:334 UGFzc3dvcmQ6\r\n(リターン)「Password:」をBase64に変換したものです。
c:yyyyyyy\r\n(リターン)
s:235 --------\r\n(リターン)
」という形になります。（c:はクライアントが送信、s:はサーバーが送信）
xxxはユーザーIDをBase64に変換したもの、yyyはパスワードをBase64に変換したものです。---の部分はサーバーごとの異なります。
これもPLAINと同じでセキュリティ面では甘いです。
|
第05回SMTP認証（CRAM-MD5)について
|
|
AUTH CRAM-MD5はSMTPで使用される認証方法で「
c:AUTH CRAM-MD5\r\n(リターン)
s:334 zzzzzzzzzzzzzzzzzzzzzzzzzzzzzz\r\n(リターン)
c:xxxxxxxxxxxxxxxxxxxxxxxxxxx\r\n(リターン)
s:235 --------\r\n(リターン)
」という形になります。（c:はクライアントが送信、s:はサーバーが送信）
xxxはBase64に変換された文字列です。zzzはBase64に変換されたタイムスタンプ（APOPについて参照）です。
動作は
１，zzzzzzzzzzzzをBase64でデコードし、タイムスタンプを得る。
２，１で得たタイムスタンプをユーザーパスワードをキーとしてMD5ダイジェスト(yyyyyyyyyyyyyyyy)を求める。
３，２で得た１６進の文字列の前にユーザーIDを加え、Base64に変換する。
(userIDyyyyyyyyyyyyyyyy → xxxxxxxxxxxxxxxxxx)
４，３の文字列を送信する。
という動作になります
ユーザーIDはBase64デコードで簡単にわかりますが、パスワードはyyyyを求めるときのキーとしか使われないのでネットワーク上にパスワードが流れる事はありません。
しかし、APOPと同じように素のパスワードがサーバー側に必要になります。
例
c:AUTH CRAM-MD5
s:334 PDIwMDQwMjI4MDkxODQzLkJERHFQZ0tHQU1nQG1haWxkYWVtb24+
(<20040228091843.BDDqPgKGAMg@maildaemon>)
c:YWRtaW4gZmI5ZmY5ODM0NjM1Yjk3NjVlMjU3MmVlNTY2Yjg0ODU=
(admin fb9ff9834635b9765e2572ee566b8485)
s:235 2.0.0 Authentication successful
このときのユーザーIDとパスワードはそれぞれ「admin」です。
()内はBase64デコードした物です
|
第06回ＭＩＭＥＢエンコードについて
|
|
ＭＩＭＥＢエンコードは主にヘッダで日本語を使用したいときに使われます。
「=?iso-2022-jp?B?____?=」（___の部分はBase64です）という形です。（iso-2022-jpは大文字でもかまいません）
まず、文字をJIS（iso-2022-jp）に変換します。そして、Base64に変換します。変換するのは日本語の部分だけでASCII文字の一部（英数字など）は
変換する必要はありません。
複数回使用することも可能ですがBase64に変換された中では日本語エスケープ状態ではいけません。
（[ESC]$Bの途中ではいけない、ASCIIで終わっているか[ESC](Bで終わっていなければならない）
長い日本語を使用するときは注意が必要です。（変換したサイズが長いと通信途中で強制的に改行される場合があり、そうするとうまくデコードできなくなる場合がある）
本来はファイル添付時のファイル名に使用してはいけないのですが、慣例的に使用されています。
（本来はRFC2231準拠していなければならないが対応していないソフトが多いため、対応していてもＭＩＭＥＢエンコードで送らざるを得ない）
例
=?ISO-2022-JP?B?TUlNRSBCGyRCJE4lKCVzJTMhPCVJJUYbKEI=?=
=?ISO-2022-JP?B?GyRCJTklSBsoQg==?=
「MIME Bのエンコードテスト」をＭＩＭＥＢエンコードした物です。
|
第07回ＲＦＣエンコードについて
|
|
ＲＦＣエンコードは主に添付ファイル名で日本語を使用したいときに使われます。
「iso-2022-jp''___」（___の部分はquoted-printableです）という形です。（iso-2022-jpは大文字でもかまいません）
まず、文字をJIS（iso-2022-jp）に変換します。そして、quoted-printableに変換します。
本来ならば添付ファイルにはこちらの形式を用いなければならないのですが、対応しているソフトは少ないです。
例
filename*0*=iso-2022-jp''RFC2231%1B%24B%3D%605r%24N%25%28%25s%253%1B%28B;
filename*1*=iso-2022-jp''%1B%24B%21%3C%25I%25F%259%25H%1B%28B
「RFC2231準拠のエンコードテスト」をＲＦＣエンコードした物です。
|
