=================================================== タイトル : 電子メールと標準化の動向 発表者 : Eric Allman(Sendmail Inc.) 記録者 : 馬渡(ユーテック)、北口(インテック・システム研究所) 日時 : 1999/12/14(tue) 15:30〜16:50 =================================================== - 電子メールと標準化の動向 - Eric Allman (Sendmail Inc.) 1.Email利用のStandard 過去と将来の実装 2.Outline ・関連標準の歴史 ・進行中の作業 ・実装とスタンダードのかかわり合い(メッセージトラッキング)将来実装 ・将来出てくるStardard 効果的なコミュニケーションの利用 3.Historical background RFC733 ARPANET(インターネットの前身)で重要だったもの メッセージフォーマット RFC542(FTP) 基本的に標準化した FTP 電子転送をアノニマスに届く UUCP UNIX サイド UNIX mailbox format RFC733 と同じ時期 UNIX 伝送の一部 リリースごとに変わっていく(文書化されていない) 4.Early Internet Standards スタンダードをもっとはっきりさせようという動き RFC821 ARPANET => インターネット SMTP を定義したもの もともと FTP をベースにしたものなので、FTP に似たもの RFC822-update of RFC733 もう1つの当時の標準 メッセージのフォーマットを update 5.MIME Stardard RFC822 にはいくつかの問題があった 7bit アスキーテキストのみ(マルチメディアの扱いが出来ない) 7bit 以外(日、フランス、ロシア)が対応出来ない Extended RFC822 to go beyond 7bit ASCII Nathanial Brorenstein 1992 このような問題に対応 MIME を開発 基本的に 7bit を変えずに 7bit のなかに 8bit を入れる 両端のマシンで対応した MUA を使う必要があった 6.Extended SMTP 上記までの対応でも不備があったので、IETFにていくつかの Extention  が追加された(IEFT 1993) さまざまなフォーマットの追加 パワーが足りないので拡張できない Extension Mechanism for SMTP プロトコルの拡張が出来るようになった some basic extension include ESMTP と同じ時期に追加 size extension サイズを伝える ESMTP 8bit のテキストを送る事も出来る様になった 7.Delivery Status Notifications  bounceメッセージの標準化(IETF 1996) Standard error message format include "success" notification 問題がまだまだあった エラーメッセージの標準化 なぜ送れなかったかの情報すらないメーラーも存在した エラー問題の解決 DSN MIME と SMTP にまたがる仕様 いつデリバリーされたか遅れるか発生するのか DSN は MIME と SMTP 両方を必要 DSN の特徴 送信の確認(メイルボックスに入ったかどうか) ※ノンスタンダードではない 8.Message Disposition Notification DSN に限界 メイルが届いたかだけの確認(その後の処理は分からない) メイル BOX に入った後の確認 MDN :上記の機能を補完するもの(SMTPとは関係無い) MUA 上で実装されるべきもの MDN の問題 MUA のなかでインプリ MUA の実装は多いため、普及は遅れる 9.Security & Privacy スタンダード以外の問題-セキュリティ IETF 1999(暗号化、S/MIME) 2つの機能 ディジタルシグニチャ(電子署名) 受取人が本人であるかどうかを確認 受け取ったことの証明 プライバシーの確認 暗号化 受取人だけが読める 暗号化 政治的なポリティックスに関わるので大変 S/MIME は、RFC ドラフトは今年出たばかり 10.Directory Services S/MIME 問題 鍵の受け渡しが重要 誰のカギであるかを保証できなければならない => これは非常に困難である ディレクトリサービス 限られた狭い範囲では LDAP で保証する事が出来る しかし、LDAP と MUA 間で標準化されたスキーマが必要 11. SMTP Authentication and Encryption(SMTPのレイヤで暗号化する) SMTP-SMTP & Transport Layer Security(TLS) 絵にはTLSをつっこんでおく(スペースがないので) どちらもMTA間での暗号化 メイルBOX間ではS/MIMEの方がセキュリティが高い 鍵管理はS/MIMEより楽 AUTHのしくみ SMTPリレーにも使える 捏造防止に利用できる(電子署名での利用はできないが) 12.Current Standard Work 今の状況活動 いろいろなグループ DRUMS RFC821,822をひとつにまとめる (MTA,MUAを実装するときRFCのいろいろなところを よまないといけない) 理論上の新規追加はしない(基本的に) 使わない機能の削除 マイナーな微調整 さらにほかのグループ MIMEでほかのメディアに対応させる(FAX over MIME) S/MIMEの作業をすすめる PKI(私の目の黒いうちは終わらない) 別のグループ LASER Emailのルーティング用にLDAPを使う LDAPのスキーマを決める 13.Message Tracking もうひとつ Message Tracking Work Group 今どこにメイルがあるのかをなどをトラッキングして 調べる仕組み(送信した後探しに行く) DSN,MDNとうまく統合化されている ついてしまっているものはTrackingする必要無い S/MIMEとの統合化 DSN自体が捏造されないようにする 14.Message Tracking Detail DSNにサインをつけてセキュリティを高める 送信者にDSNが帰ってくればOK DSNが帰ってこない場合 何らかの仕組みでメーラに対してプローブをかけ MTAのステータスという形で問い合わせる どのメイルか特定するため、何らかのハンドルをする (エンベロープIDなどを利用) DSNのようなステータス情報をINBOUNDで同じコネクション のなかで送る Senderは間違い、正しくはMTA 15.Message Tracking Model MUAからメッセージを送信する これに対してどういうメッセージを送るかを知らせる (Tracking AgentがメッセージIDなどを付けておく) 間に入るMTAを介する 中継するMTAは情報を入れていく(MTAに渡していく) 最後のMTAでメイル配信 最後のMTAが到達メッセージを送信者に返す メイルBOXに入ったあとDSNを介す 帰ってくるときもともとのTracking Agentに入る(どこの宛先にはいったか) DSNが帰ってこない場合 Inter MTAにプローブかける Tracking Databaseにデータを渡す(記録する) 16.Message Issue Massage Trackingの課題 POPにおいてその情報を格納する どの情報をストアする必要があるかどこで削除するか 全部はコストがかかる ユーザが指定する事が重要(なにが重要な情報が指定する方法) データのリトリーブをする SMTPのエクステンションか新しいサービスか FireWallをトンネル(どのような意味を持つか) センターとリトリーブのどちらに責任をもたせるか Working Groupでいろいろ話し合いをしている 17.A World about Implementation   Standardを書いただけではしょうがない   実装する事が必要(有益性が高まる) StandardとImplementationに間がある 18.Future Standard Work 解決できないものが多い 電子署名についての標準化 S/MIMEの普及に鍵管理が必要 スケーラビリティ メイルの利用が高まる QoSが必要 将来の標準化の課題 トランザクショナルなEmail 再送信で届かない場合 2つのコピーがある場合、2つ目のコピーが破棄されるべき (トウベキ) 19.Transaction デリバリーの保証 認証の保証 一意性の保証 S/MIMEの上のまた他の標準(頂上に置かれる) 20.Implication トランザクションメッセージ Emailの技術として必要なもの インタラクションをするために使うアプリ RPCはローカルならうまく行く 分かっている場合にはHTTP Push型の需要 サポート メイルをコミュニケーションツールとして使う場合に 重要なのはネットワークの堅牢性 SMTPコミュニケーション解決しなければ行けない問題がある SMTPAuth =-=-= 質疑応答 =-=-= Q1 日本のISPではPOP before SMTPを使っていてなかなか新しいものを使おうと しないここで日本のISPにSMTPAuthを使うように啓蒙してほしい A1 ワークアラウンドでしかない POP bofore SMTPは付け焼刃でしかない SMTPAuthをユーザで理解する必要がある MTAで実装していくのは自分の仕事としてがんばる sendmail8.10ではサポートする Q2 MDNのついているメイルをIMAPメーラでユーザごとのシェアードフォルダに アクセスするとユーザごとに応答が帰ってくる MDNのついたメイルをIMAPのフォルダに入れると、たくさんの人が見る事になる。 この場合IETFではどのように考えているのか? A2 私はあんまり考えた事が無い(どんな対応になるか) 2つ目のメッセージのヘッダを取る Q3 メイルリストに対する拡張について特別な考えはないのか? A3 LDAPのスキーマの討議がなされている Work Groupとしてはまで討議は行われていない 人が移動してもデリートしない バウンスをハンドリングする機能が必要 Q4 暗号化はSSLを使う形でも良いか A4 SMTPAuthは担当ではないので詳しくないがSASLでやっている 基本的に、SSLはいくつかのアプリで使用している TLSが出てきた時はSSLをベースにやってきている(SSLのほうがポピュラー) sendmailで使う場合に問題になるのはTLSは世界中で使う事は難しい TLSは輸出規制のため世界中に配る事ができない (SMTPAuthのほうが利用しやすい) SMTPAuthのほう簡単に配る事が出来るのではやいかも Q5 LDAPのところはACAPだとそのままなのだが ACAPでLDAPは置き換える事が可能なのでは A5 ACAPを良く知らない LDAPは多くのところで利用されている 良いものが残っていく訳ではない(多く普及したものの勝ち) 少なくとも生き残るのはX.500ではない Q6 SIP(Session Initiation Protocol)は構想に入っているのか A6 SIP(Session Initiation Protocol)はIETFに独立したWorking Group がある。(DRUMSには含まれない) そこからドラフトを出す SIP(Session Initiation Protocol)は独立したスタンダード Q7 Message Tracking Modelでは間のMTAが重くなるので、FireWall が使えなくなるのでは? A7 FireWallには対応していない課題ではある しかし、(郵便小包と同じように入り口である)FireWallまで届けば 良いという考えもある。 いつかTIS FireWallでサポートするかもしれない Q8 MTAの前にLocalDirectorが入っている場合 A8 LocalDirectorの事は考えていなかった Q9 Mr.Ericは何通のメイルを読んでいるのか A9 200〜300通/日メイルが届く メイルリストのメイルはthrow awayする 以前に読まなくては行けないメイルのチェックをしたとき、メイルの数4500通 あったが今のところ読まない予定、読むつもりが無い ===================================================