メインコンテンツまでスキップ

11. その他の問題

このセクションでは,この仕様セットの一部として,カバーされていない,または包括的にカバーされていない問題を特定しますが,電子メールアドレスおよびヘッダ国際化部署の一環として継続的なレビューを必要とする.

11.1. URI及び IRIへの影響​

メールへの:スケーマ [RFC6068],および国際化資源識別子 (IRI) 仕様 [RFC3987]での議論は,この作業が完了し標準化されると変更されることが必要かもしれません.

11.2. 識別子としてのメールアドレスの使用​

現代インターネット利用では,電子商取引サイトや一部のX.509証明書 [RFC5280] に対応する Web サーバーの識別子として,個人向け識別子として電子メールアドレスが使用される場所がいくつかあります.これらの文書ではこれらの用途に対処していませんが,国際化アドレスが最初にこれらの文脈で使用されると,いくつかの困難が発生すると予想することは合理的です.その多くは,今日許可されているすべてのアドレスを処理することもできません.

11.3. 符号化語,署名済みメッセージ,ダウングレード​

メール形式の特徴の 1 つは永続性である.MUA は数秒前に配信されたものだけでなく,数十年前に送信されたメッセージも処理できることが期待される.したがって,MUA や Sieve [RFC5228] などのメールフィルタリングソフトウェアは,一部のヘッダーフィールドで non-ASCII 文字を表す encoded-word [RFC2047] を引き続き受理し復号する必要がある.POP3 [RFC1939] と IMAP [RFC3501] には,RFC 2047 の復号を含め,符号化された non-ASCII 情報を持つメッセージをサーバー側で自動的にアップグレードする拡張が定義されている.

例えば,S/MIME [RFC5751] や Pretty Good Privacy (PGP) [RFC3156] で暗号学的に署名されたメッセージ部分は,署名を壊さずに RFC 2047 形式から通常の UTF-8 文字へ変換できない.暗号化されたメッセージ部分も,復号後に RFC 2047 符号化のヘッダーフィールドを含む場合があり,暗号鍵へアクセスできなければ完全にはアップグレードできない.

署名済みメッセージを 8.1 節のようにダウングレードし,後で元の形式へ戻して署名を検証する場合も同様である.ダウングレードと再アップグレードで生じるごく小さな変更でも,主要ヘッダーまたは MIME body part header に影響すれば署名を無効にし得る.署名がある場合,ダウングレードは可能な限り避け,行うなら極めて慎重でなければならない.

11.4. ローカル部のその他の用途​

ローカル部はドメインラベルの構築に使われることがある.例えば,[email protected] のローカル部 user をホスト名 user.domain.example に変換し,Web 空間を http://user.domain.example に置き,包括アドレスを [email protected] とする場合である.

これらの制度は,他のものなど,ドメイン名に関するSMTP規則によって制限されていることは明らかであり,他の地域ではさらなる制限なしに機能しない.これらの制限がこれらの仕様に関連しているかどうか,それは開かれた問題である.これは,配送MTAに受け入れられるメールボックス名と解釈の決定において与えられたかなりの柔軟性の別の例である.

11.5. 非標準のカプセル化形式​

いくつかのアプリケーションは,RFC 2046第5.1.5節 [RFC2046] で定義されたメッセージ/消化形式の代わりに,アプリケーション/mbox フォーマット [RFC4155] に似たフォーマットを使用し,複数のメッセージを単一の単位として転送する.そのようなアプリケーションは,すべての保存されたメッセージがRFC 2046第5.2.1節 [RFC2046] で記述されたメッセージ/rfc822 フォーマットを使用すると仮定するので,これらの文書シリーズで指定された拡張機能に準備ができていないため,それらを適切に検出し処理するために特別な措置が必要になる可能性があります.