6. 考慮事項

6.1. セキュリティに関する考慮事項

このドキュメントでは、既存のインターネットメールアーキテクチャについて説明しています。新しい機能は導入していません。この展開されたアーキテクチャのセキュリティに関する考慮事項は、このドキュメントで参照されている技術仕様に広く記載されています。これらの仕様は、認証やプライバシーなどの古典的なセキュリティトピックをカバーしています。たとえば、電子メール転送プロトコルは、認証および/または暗号化されたリンクを介した操作に標準化されたメカニズムを使用でき、メッセージコンテンツにも同様の保護標準を利用できます。このようなメカニズムの例には、SMTP-TLS [RFC3207]、SMTP-Auth [RFC4954]、OpenPGP [RFC4880]、および S/MIME [RFC3851] があります。

インターネットメールアーキテクチャのコアは、エンドツーエンドまたはホップバイホップのコンポーネントにセキュリティ要件や機能を課しません。たとえば、参加者の認証を必要とせず、データの開示を防ごうともしません。

特定のメッセージ属性は、特定のセキュリティ上の考慮事項を露呈させる可能性があります。たとえば、アーキテクチャのブラインドカーボンコピー機能は、[RFC5321] のセクション 7.2 および [RFC5322] のセクション 5 で説明されているように、開示の懸念を招きます。このアーキテクチャでのテキストまたは非テキストコンテンツの転送には、[RFC5322]、[RFC2045]、[RFC2046]、および [RFC4288] で説明されているセキュリティ上の考慮事項があります。また、IANA に登録されているメディアタイプの一部にもセキュリティ上の考慮事項があります。

電子メールに自動的に応答するエージェントは、[RFC3834] で説明されているように、重大なセキュリティ上の考慮事項を提起します。ゲートウェイの動作は、[RFC2480] で説明されているように、エンドツーエンドのセキュリティサービスに影響を与えます。境界フィルタに関するセキュリティ上の考慮事項については、[RFC5228] で説明されています。

発信元検証のトピックの議論については、[RFC5321] のセクション 7.1 を参照してください。セクション 4.1.4 で述べたように、このアーキテクチャのコンポーネントが RFC0791.SourceAddr を使用してポリシー決定を行うことは一般的ですが [RFC2505]、アドレスは「なりすまし」される可能性があります。許可なしに使用することが可能です。SMTP およびサブミッション認証 ([RFC4409], [RFC4954]) は、より安全な代替手段を提供します。

このドキュメントにおける信頼境界、ADMD、アクター、役割、および責任の議論は、インターネットメールサービスの運用におけるセキュリティ要因の関連性と潜在的な複雑さを浮き彫りにしています。オープンでカジュアルなメッセージ交換を促進するためのインターネットメールのコア設計は、問題のある慣行を持つ人々を含むように電子メール参加者の人口が増加するにつれて、スケーリングの課題に直面しています。たとえば、[RFC2505] で定義されているスパムは、このアーキテクチャの副産物です。この主題に関する多数の標準化過程または BCP ドキュメントが発行されています（[RFC2505]、[RFC5068]、および [RFC5235] を参照）。

6.2. 国際化

コアのインターネット電子メール標準は、US-ASCII の使用に基づいています。つまり、SMTP [RFC5321] と IMF [RFC5322]、およびそれらの前身です。これらは、厳密に US-ASCII 7 ビットエンコード文字で構成されるメッセージの転送と構成を記述しています。標準は、下位互換性のメカニズムを維持しながら、この制限されたセット外の文字を許可するように段階的に強化されています。具体的には：

• MIME 仕様 ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) は、US-ASCII 以外のコード化文字セットおよび文字エンコードスキーム（MIME 用語では「文字セット (charsets)」）の使用を許可します。MIME の [RFC2046] では、メッセージのテキストコンテンツに、そのコンテンツで使用されている文字セットを指定するラベルを貼付できます。同様に、MIME の [RFC2047] では、メッセージ内の特定のヘッダフィールドのテキストコンテンツに同様のラベルを付けることができます。ただし、メッセージは 7 ビットエンコード文字の転送のみが可能な SMTP 実装を介して転送される可能性があるため、MIME の [RFC2045] は、他の文字セットの文字を US-ASCII へのオーバーレイとして再エンコードできるように「コンテンツ転送エンコーディング (content transfer encoding)」も提供します。

• MIME の [RFC2045] では、メッセージのテキストコンテンツを 8 ビット文字エンコードスキームにすることができます。これらを再エンコードせずに転送するために、SMTP 仕様は、そのようなテキストコンテンツの転送を許可するオプション [RFC1652] をサポートしています。ただし、[RFC1652] オプションはメッセージヘッダフィールドでの 8 ビットコンテンツの使用には対応していないため、それらには依然として [RFC2047] エンコーディングが必要です。

• 電子メールアドレスの国際化 (EAI) に関する一連の実験的プロトコルがリリースされ、SMTP と IMF を拡張して、アドレスおよびメッセージのヘッダフィールド全体のその他の情報に 8 ビットエンコード文字を表示できるようになりました。[RFC5335] は、そのようなメッセージヘッダフィールドの形式（文字を UTF-8 でエンコードする）を指定し、[RFC5336] は、これらのメッセージの転送のための SMTP オプションを指定します。

• MIME の [RFC2045] および [RFC2046] は、真のマルチメディア素材の転送を許可します。このような素材は、特定の言語やロケールに制限されないため、国際化を可能にします。

• 配信状態通知 (DSN -- [RFC3462], [RFC3463], [RFC3464]) およびメッセージ処分通知 (MDN -- [RFC3798]) の形式には、通知の構造化表現と非構造化表現の両方が含まれています。非構造化表現が間違った言語であるか、その他の理由で使用に適さない場合、これにより、MUA はユーザに表示するために通知の独自に適切にローカライズされた表現を構築できます。

• POP と IMAP は、8 ビットを含む MIME メッセージの処理に問題がないため、国際化の問題の原因ではありません。

したがって、UTF-8 の使用は、既存のインターネットメールで完全に確立されています。ただし、長年のエンコーディング形式のサポートは維持されており、現在も使用されています。