RFC ダイジェストー⑩ 図 2 RFC2369 て醍案されているヘッタフィールド列 Subscribe : (Use this command to J0in the list) —Subscribe : く mailto : list—request@host . com?subj ect=subscribe> Subscribe : くmailto:list@host . com?subject=subscribe> ・メーリングリストへの入会申請 He1p: く ftp://ftp.host.com/list.txt> (FTP) , くmailto:list@host. com?subject=help> HeIp: く http://www.host.com/list/>, く mailto: list—info@host . com> HeIp: くmailto:list—info@host . com> (lnfo about the list) He1p : く mailto : list—manager@host .com/body=info> He1p: くmailto:list@host . com?subject=help> (List lnstructions) ・メーリングリストに対するヘルフ餌乂得要求 List— List List— List— List— List— List— List— く mailto : list—manager@host . com?body=unsubscribe%201ist> List—Unsubscribe : (Use this command to get off the list) List—Unsubscribe : く mailto : list@host .com/subj ect=unsubscribe> ・メーリングリストへの退会申請 く mailto : list—manager@host .com/body=subscribe%201ist> List—Subscribe: く http://www.host.com/list.cgi?cmd=sub&lst=list>, List—Subscribe : くmailto:list—on@host . com> く mailto : list—manager@host .com/body=subscribe%201ist> Archive : ーく http : / / w . host .com/list/archive/> (Web Archive) Archive : く ftp : //ftp.host.com/pub/list/archive/> Archive : く mailto : archive@host .com/subJect=index%201ist> ・メーリングリストのアーカイプ Owner: く mailto :josh@foo . bar?Subject=1ist> —Owner : く mailto : grant@foo.bar> (Grant Neufe1d) Owner: く mailto : listmom@host. com> (Contact Person for He1p) ・メーリングリストの所有帯匱 Post : NO (posting not allowed on this list) Post : くmailto:moderator@host . com?subject=Iist%20posting> POSt : く mailto :moderator@host . com> (Postings are Moderated) List—Post : くmailto:list@host . com> ・メーリングリストへの投稿 List—Unsubscribe : くmailto:list—off@host . com> List— List— List— List— List List— List— List— List— 3. 切黼巣作 ます、クライアントはメールサーバーに接続すると、選 択されたメールのキャッシュコピーをクライアント側 に生成する。その後すぐに接続を切断して、メール巣 作はキャッシュに対しておこなう。操作カ鮗ると、再 度接続して柤圧の整缶生を保っため巣作をおこなう。 UIDPLUS は上記のなかて切黼盟御の性能向上のた めに利用される拡張群であり、それぞれの操作に関して最 適化されている。 UIDPLUS は、以下のような拡張から構成される。 ・ UID EXPUNGE コマンド 削余斉みフラグおよひ特定の UID が設定されたメー を一彎舌削除する。 UNIX MAGAZINE 1998.9 ノレ ・ APPENDUID 応答コード APPEND コマンドの応答の拡張。メッセージと対応 する UID を返すようにする。 ・ COPYUID ) 芯答コード 151 り、標材ヒはされていない。 RFC2359 自体は技術面での 「 IMAP4 の切断操作の実現についてはまた議論中であ RFC2359 には「 IESG note 」が付加されており、 を完了できるようになっている。 マンド発行が必要な場面において、単一のコマンドて操作 それぞ基本的な IMAP4 操作を用いると複数のコ うにする。 の拡リ複製が成功した場合に対応する UID を返すよ COPY コマンドおよび UID COPY コマンドの応答

図 1 mailto 機構の広張例 く mailto : infobot@example. com?subj ect=current—issue> く mailto : foobar@example .com/In—RepIy— To = % 3C3469A91.DIOAF4C@examp1e . com> く mailto :majordomo@example . com?b0dy=subscribe%20bamb00—I> く mailto : j oe@example. com?cc=bob@example . com&body=hello> 9. 伺録 10. 著イ表示の全文 U RL 関連 RFC2368 The mailto URL scheme mailto URlæg PS. 、 P. Hoffman 他 ( RFC1738 、 1808 更新 ) 電子メールアドレスを示す URL 形式である mailto 機 構に関する孑長を定義している。現在の状態は、標準化へ の提唱 (Proposed Standard)" である。 1998 年 7 月 13 日に公開された。 RFC1738 、 RFC1808 を史新している。 RFC1738 における mailto オ懾の定義では、 RFC822 形式のメールアドレスしか示すことかて、きなかった。 RFC 2368 では、電子メールを利用した資源の活用のために mailto 機構を拡張して、アドレス以外のヘッダ部およ びメール本体を記述できるようにしている。拡張部分は URL 符号化される。 拡彊列を図 1 に示す。 RFC2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields 主要なメーリングリスト・コマンド用のメタ構文としての U RL の禾堋と、メッセージへッダ・フィールドを禾堋し た URL のイ医 PS. 、 G. Neufeld 他 メーリングリストのコマンドを、 RFC2368 形式を利用 した URL として表現し、その内容を電子メールヘッダ内 に収容するガ去を提案している。現在の状態は、、標準化へ の提唱 " である。 1998 年 7 月 13 日に公開された。 RFC2369 で定義されるヘッタ、は構造化フィールドで あり、メーリングリストに関する情報や、メーリングリス トに対するコマンドを表現するために利用される。これら のヘッダは、メーリングリスト・サーバーから医される メールのヘッダ部分に追加される。 RFC2369 で定義しているコマンドは、 150 ・メーリングリストに対するヘルフ ( 得要求 ・メーリングリストへの入会申請 ・メーリングリストへの退会申請 の 3 つである。ー屬己のほかに、 ・メーリングリストへの才財高 ・メーリングリストの所有者清報 ・メーリングリストのアーカイプ についての形式も提案されている。 これらの URL 化されたコマンドおよび情報を電子メー ルにイ寸加することで、メール・クライアント側での処理の 自動化や、グラフィカル・インターフェイスの寒見 ( 入会 / 退会ボタンや過去のアーカイフ陬得ボタンなど ) か容易に なる。 RFC2369 で提案されているヘッダフィールドの例を 図 2 に小す IMAP4 関連 RFC2359 lMAP4 UIDPLUS extension lMAP4 UIDPLUS 拡張 PS. 、」 . Myers IMAP4 の切断操イ御芋に利用される UIDPLUS 拡張 を定義している。現在の状態は、、標準化への提唱 " である。 1998 年 6 月 18 日に公開された。 UNIX MAGAZINE 1998.9 るだけである。 おこなわれる。クライアント側からはコマンドを送信す メールカ塾占されたサーバー上でメールに対する処理が 2. オンライン操作 し端末側でメールに対する処理をおこなう。 続して、サーバーに溜まっているメールを端末イ耻・、幻 を読む端末 ( クライアント ) から定期的にサーバーに接 メッセージは共有されたサーバーに酉占医される。メール 1. オフライン操作 IMAP4 によるメール操作には、以下のものがある。

してしまうおそれがある といったように、具ー純勺に述べられている。 4 章の「 Document CheckIist ( 文書チェックリスト ) 」 には、作成した文章のチェックリストか鞨載されている。 RFC の言当レベルを理解するのに役立っと思われるため、 抜粋しておく。 ・セキュリティ上の危険生を明記しているか ? 予測される攻撃ごとに防餌策を提供しているか ? 提示されたセキュリティ対策が運用環境におよはー景 について詳しく述べているか ? ・プロトコルや手続きの目的か説明されているか ? 意図したとおりの機能やサーピスが用意されているか ? 既存のプロトコルとの関係を述べているか ? ・スケーラビリティと安定性の間題を考察しているか ? 番号割当てのガ去は IANA と共通か ? 定義しているプロトコルを管理する方法を論している か ? MIB は定義されているか ? ・対象読者を定めているか ? プロトコルてイ吏用するアルゴリズムについて言及もしく は説明しているか ? ・バケット線図を入れる場合、それは推奨する形式のも のか ? 変更点の言求はあるか ? 以則のバージョンがある場合、そのバージョンとの違い をしているか ? 要求ごとに説明を分けているか ? プロトコル操作の例を提供しているか ? ・他の実装によって不正な操作がおこなわれた場合の料カ を定義しているか ? ・受け取って処理すべきバケットと無視するバケットの 境界を日寉にしているか ? ・ある要求について複数のがある場合、そのなかから 1 つお尺できるようになっているか ? 付加機能をいくつ定義しているか ? それらはイ寸カ日機能クラス別になっているか ? すべての付加機能もしくは付加機能クラスの組合迂を個 別に説明しているか ? 付加機能の原理および使用法を説明しているか ? UNIX MAGAZINE 1998.9 RFC ダイジェストー⑩ ・すべての必頭ない凵寸加的な要求を、インターネットに おける要求水準を示すものとして認められたキーワード によって定義、言当しているか ? ・ IETF の国ド勺ポリシーに従っているか ? ー勺なインターネット用語を推奨される意味で使用し ているか ? ・インターネット用語を特別な未て使っている場合、用 語集部分で再定義しているか ? 以下に RFC2360 の目次を示す。言己されている内容 2. 共通ガイドライン の概要を知るための参考にしてもらいたい。 用語集 2.17. 国際化 2.16. ネットワークの安定生 スケーラビリティに関する考察 ネットワーク管理に関する考察 IANA に関する考察 表記刎列 要求レベルの提示 2 , 10. プロトコル・オプションの操作 2.9. 送信 / 受讎の力に関する規則 2.8. 信から外れた重川行の応答 2.7. 開発の経緯 2.6. フ。ロトコノレのノヾージョン 2.5. 変更の言当求 2.4. 記の田さの水售 2.3. 対象読者 2.2. プロトコルについての言当 2.1. セキュリティについての言義 2.18. 2.15. 2.14. 2.13. 2.12. 2.11. 3. 個別ガイドライン 7. 謝辞 6. 参考文献 5. セキュリティに関する考察 4. 文書チェックリスト 3.3. 状態マシン (state-machine) の言当主 3.1. ノヾケット糸喇図 8. 編者の ; 叫各先 149