などの、メッセージの長さや形式に制限 (ASCII 文字で 数百バイト以ード ) のあるテパイスによる通信のみである。 インターネット FAX 関連 RFC2531 Content Feature Schema forlnternet Fax インターネット FAX 用のコンテント特性スキーマ PS. 、 G. Klyne 他 インターネット FAX 間で性能の識別に利用されるコン テント特性スキーマを定義している。現在の状態は、、標準 化へ窈是唱 " である。 1999 年 3 月に公開された。 インターネット FAX において拡張機能が用いられる 場合には、性能の識別に、、メディア持性 " か利用される。 RFC2531 では、メディア特性を登録する機構に対する 登録情報形式である、、コンテント持性スキーマ " を定義し ている。このスキーマを利用することで、インターネット FAX とグループ 3 FAX 用の TIFF ファイル形式で扱わ れている範用の性能を登録できる。 RFC2531 では、 ・ FAX 搨生を言当するための文法全体 ・インターネット FAX の匪能表示用の特生タグ か定義されている。特生タグには以、下の不鶤頁がある。 ・画像符号化 ・・色モテフレ ・色性能 ・紙のサイズ ・メディアタイプ ・解像度 ・画象サイズ UNIX MAGAZINE 1999.5 窈是唱 " である。 1999 年 3 月に公開された。 追加され剞生を定義している。現在の状態は、、標準化へ インターネット・メールを利用する FAX への長と、 PS. 、 L. Masinter 他 インターネット・メールを不堋した FAX の拡張 RFC2532 Extended Facsimile Using lnternet Mail 録手続きて規定された形式で用意されている。 性用の追加特性タク当が、 RFC2506 のメディア搨生登 また、刊録 A では、 FAX に特有の新しいメディア特 RFC ダイジェストー・ を置き換える RFC として 1998 年 12 月に公開された。 状態は、、標準化への提唱 " である。 RFC1455 、 RFC1349 フィッククラス・フィールドの未を規定している。現在の を利用するために、 TOS (Type Of Service) およびトラ IPv4 および IPv6 において区分化サービス (diffserv) PS. 、 K. Nichols 他 ( RFC1455 、 RFC1349 置ま奐 ) IPv4/v6 ヘッダにおける DS ( 区ヒサービス ) フィール Field ()S Field) in the 旧 v4 and 旧 v6 Headers RFC2474 Definition of the Differentiated Services 区分化サービス (diffserv) 関連 の 3 段階の優先立を付けて提示している。 3. 有用 2. 重要 1. 不可欠 さまざまな事項について、 インターネット FAX 用プロトコルにおいて要求される ネット FAX うト会の目標を記している。 ネット FAX に里する用語の定義と、 IETF のインター の機能判定の基準を確立することを目的として、インター RFC2542 では、インターネット FAX 用プロトコル として 1999 年 3 月に公開された。 ネット FAX 分科会の目標について述べている。、、広報 " インターネット FAX 関連の用語を定義し、インター fo. 、 L. Masinter インターネット FAX の用語と目標 RFC2542 Terminology and Goals forlnternet Fax の 2 つの標準イ甘是案されている。 3 章 : 追加の文謝罸生 G 尺 ) 2 章 : 醋医確認 ( 必彡却 的機能を利用できるようにするために、 た操作生を提供し、確実な醋斷忍、、処理告知などのも RFC2532 では、既存の MTA や MUA と共通化され を記している。 像度や色 ) の拡張、醋逶および処理の石忍などの追カ財罸生 lnternet Mail 」 ( RFC2305 ) への才長と、文書吽剞生 ( 解 RFC2532 は、「 A Simple Mode of Facsimile Using 143

図 1 SMTP における TLS キ盾 ( 誌面の都合上、で折り返しています ) ( そのまま SMTP コマンド発行を継続 ) c & s : ( 折衝結果のチェック ) c & s: (TLS 折衝 ) ( TLS 折衝開始 ) 220 Go ahead C : STARTTLS S : 250 STARTTLS welcome 250 ー mail . imc. org offers a warm hug of EHLO mail . ietf . org 220 mail. imc. org SMTP service ready ( 接続開始 ) (TCP ポート 25 監視 ) c : c : S : S : C : S : c : s : 142 fo. 、 M. Banan Neda 社による EMSD プロトコ ) 士様 livery (EMSD) P 「 otoc Specification Version 1.3 RFC2524 Neda's Efficient Mail Submission and De- 要になると予測している。 が、スバム問題は技行祕北いうよりも社会的な対応策が必 IETF では抜本的な鮹夬策についても言侖を進めている などにおけるスバム対策を提示している。 ・ MUA (Mail User Agent) ・ DNS といった酉当時における対策をはしめ、 ・アドレス情報にもとづく醋医制限 ・さまざまなメールヘッタ情報にもとづく制限 RFC2505 では、 ている。 本的な対策を検討する時間的な余裕か得られると考えられ バムがはびこっている現状は改善されるだろうし、より抜 ネット上の多くの SMTPMTA に適用されることで、ス こで提案されているさまざまな推奨事項がインター い。抜本的な対策に至るまでの日判り稼ぎ的な側面カ伏きい RFC2505 で提案されているガ去は最良のものではな としても公開されている。 て 1999 年 2 月に公開された。 BCP シリーズの BCP 30 、王知寺点での最良のカ 1 去 (Best Current Practice)" とし いて、実装に関するさまざまな推奨恥頁を提示している。 SMTP および MTA レベルでのスバムメール対策につ 短い電子メールメッセージの提出や配送に最適化され た、 EMSD (Efficient Mail Submission and Deliv- ery : 効果的なメール提出 / 配送 ) プロトコルと、 EMSD 形式の符号化を定義している。、、広報 " として 1999 年 2 月に公開された。 EMSD プロトコルは、 ESRO (Efficient Short Re- mote Operations : 効果的な矢可間の遠隔処理 ) プロト コル ( RFC2188 ) 上で動作する、信頼性の高いコネクシ ョンレスのメール提出 / 酉占医サービスである。とくに、短 い電子メールメッセージ窈是出や醪用として言 t されて いる。 RFC2524 によれば、既存のインターネットメール・プ ロトコルが、 ・単純であること ・従来の SMTP に準していること を重視しているのに対し、 ESRO を利用する EMSD は 効率性を重視している。 当初、 EMSD は無線ネットワーク (CDPD 、無線 IP 、 移動 IP など ) 上での利用を想定していた。無線環境で EMSD を利用すると、 IP による双方向のページング・ サーピスとして認識される。 RFC2524 の冒頭には「 IESG Note 」が追加されてお り、以下のような制限事項カべられている。 EMSD プロトコルには、 ・輻輳制御構がない ・認朝 E 欟冓が平文パスワードのみのため、セキュリティが 不寸吩である ・文字セットカ咽際化されていない ・インターネット・メールとの相カ鮟続についての定義が 不十分である といった問題があるため、ノウ・リックなインターネット 上でのメッセージ酉当医には適当ではない。推奨される用途 は、 ・適切なリンク層符号化を利用し、ノウ。リックなインター ネットへはゲートウェイを通る無線リンク 十分な譿蒲か整っているか、なんらかの輻輳制御ができ るプライベート IP ネットワーク UNIX MAGAZINE 1999.5

RFC ダイジェストー・ メッセージ処理を、、提出 " と、転送 " に分割するメリッ 5.2. 工ラーの求 トとして、開発者やネットワーク管理者か容易に以下の事 6. オプション重川乍 項を寒見できるとしている。 6.1. 提出規定の遵守 6.2. 認証の要求 ・セキュリティの強化 6.3. 権限の遵守 ーセキュリティ・ポリシーの実装 6.4. メッセージのデータのチェック ー許可されていないメール中継のキ色 7. SMTP の拡張に対する景 ーバルクメールの配送の拒絶 8. メッセージの変更 ッセージの認証 8.1. Sender フィールドの付加 ーメッセージに対する認証の見 8.2. Date フィールドのイ寸加 ー移動中のユーサーがサイト外からメールを送る場合 8.3. Message-ID フィールドの刊カ日 などのサポート 8.4. 伝送時の符号化 ・ソフトウェア保守の簡田翻ヒ 8.5. メッセージへの署名 ー彳齬リに応しオペースコードの利用 ーサーピを供するプ 0 グラ 0 う 8.6. メッセージの日普号イヒ 8.7. ェイリアスの角夬 ・成疋ミスの検出 8.8. ヘッダの書換え ーメール・クライアントの設定ミスなどの検出 9. セキュリティに関する考察 ・提出サービスの拡張 RFC2476 では、これらの前提をもとに RFC2487 SMTP Service Extension for Secure SMTP over TLS ・提出工ージェントの SMTP 拡張 TLS を不堋したセキュア SMTP ・メッセージの変更 PS. 、 P. Hoffman ・ SMTP の才長 SMTP での通信に、 TLS によるトランスポート層レベ を定義している。 ルのセキュリティを付加するための拡張を定義している。 RFC2476 で扱っている内容を示すために、以下に 主要 現在の状態は、、標準化への提唱 " である。 1999 年 1 月に な目次を挙げる。 公開された。 TLS は、 SSL として知られているセキュリティ層であ 1. 概要 る。 TCP での通信を暗号化する欟冓として、 HTTP と 2. この文書について 並んでひろく利用されている。 2.1. 用言 ) 定義 RFC2487 では、 TLS を SMTP て利用するための方 2.2. 凡例 法を定義している。 SMTP を拡張し STARTTLS という 3. メッセージ窈是出 SMTP コマンドを定義することで、クライアントとサー 3.1. 提出の識別 バー間の通信で途中から TLS 層に移行できる。クライア 3.2. メッセージの色 / (bounce) ントから STARTTLS コマンドが発行されると TLS 層 3.3. 認証付提出 折衝 (negotiation) か開始さ以降のトラフィックは 3.4. 状態コードの拡張 暗号化される ( 図 1 ) 。 4. 必彡カ作 4.1. 汎用窈是出手色コード RFC2505 Anti-Spam Recommendations for SMTP 4.2. すべてのドメインが FQDN であることの一正 MTAs 5. 推奨動胙 SMTP MTA での対スバム推奨 5.1. アドレスの去の遵守 BCP. 、 G. Lindberg 保 BCP30) 141 UNIX MAGAZINE 1999.5