[要約] RFC 7103は、異常な形式のメッセージの安全な取り扱いに関するアドバイスを提供するものであり、目的はネットワークプロトコルの実装者に対して、異常なメッセージの処理方法を指示することです。
Internet Engineering Task Force (IETF) M. Kucherawy
Request for Comments: 7103 G. Shapiro
Category: Informational N. Freed
ISSN: 2070-1721 January 2014
Advice for Safe Handling of Malformed Messages
不正なメッセージを安全に処理するためのアドバイス
Abstract
概要
Although Internet message formats have been precisely defined since the 1970s, authoring and handling software often shows only mild conformance to the specifications. The malformed messages that result are non-standard. Nonetheless, decades of experience have shown that using some tolerance in the handling of the malformations that result is often an acceptable approach and is better than rejecting the messages outright as nonconformant. This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance.
1970年代以降、インターネットメッセージ形式は正確に定義されていますが、ソフトウェアのオーサリングと処理では、仕様への準拠が緩やかであることがよくあります。結果として生じる不正な形式のメッセージは非標準です。それにもかかわらず、何十年にもわたる経験から、結果として生じる奇形の処理にある程度の許容度を使用することは、多くの場合許容できるアプローチであり、メッセージを不適合として完全に拒否するよりも優れています。このドキュメントには、さまざまな一般的な不正メールの状況に関して利用可能な最良のアドバイスのコレクションが含まれています。実装ガイダンスとして使用されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7103.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7103で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. The Purpose of This Work . . . . . . . . . . . . . . . . 3
1.2. Not the Purpose of This Work . . . . . . . . . . . . . . 4
1.3. General Considerations . . . . . . . . . . . . . . . . . 4
2. Document Conventions . . . . . . . . . . . . . . . . . . . . 5
2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Invariant Content . . . . . . . . . . . . . . . . . . . . . . 5
5. Mail Submission Agents . . . . . . . . . . . . . . . . . . . 6
6. Line Termination . . . . . . . . . . . . . . . . . . . . . . 7
7. Header Anomalies . . . . . . . . . . . . . . . . . . . . . . 8
7.1. Converting Obsolete and Invalid Syntaxes . . . . . . . . 8
7.1.1. Host-Address Syntax . . . . . . . . . . . . . . . . . 8
7.1.2. Excessive Angle Brackets . . . . . . . . . . . . . . 8
7.1.3. Unbalanced Angle Brackets . . . . . . . . . . . . . . 8
7.1.4. Unbalanced Parentheses . . . . . . . . . . . . . . . 9
7.1.5. Commas in Address Lists . . . . . . . . . . . . . . . 9
7.1.6. Unbalanced Quotes . . . . . . . . . . . . . . . . . . 10
7.1.7. Naked Local-Parts . . . . . . . . . . . . . . . . . . 10
7.2. Non-Header Lines . . . . . . . . . . . . . . . . . . . . 10
7.3. Unusual Spacing . . . . . . . . . . . . . . . . . . . . . 12
7.4. Header Malformations . . . . . . . . . . . . . . . . . . 13
7.5. Header Field Counts . . . . . . . . . . . . . . . . . . . 13
7.5.1. Repeated Header Fields . . . . . . . . . . . . . . . 14
7.5.2. Missing Header Fields . . . . . . . . . . . . . . . . 15
7.5.3. Return-Path . . . . . . . . . . . . . . . . . . . . . 16
7.6. Missing or Incorrect Charset Information . . . . . . . . 16
7.7. Eight-Bit Data . . . . . . . . . . . . . . . . . . . . . 18
8. MIME Anomalies . . . . . . . . . . . . . . . . . . . . . . . 18
8.1. Missing MIME-Version Field . . . . . . . . . . . . . . . 19
8.2. Faulty Encodings . . . . . . . . . . . . . . . . . . . . 19
9. Body Anomalies . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Oversized Lines . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
11.1. Normative References . . . . . . . . . . . . . . . . . . 20
11.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 23
The history of email standards, going back to [RFC733] and beyond,
contains a fairly rigid evolution of specifications. However,
implementations within that culture have also long had an
undercurrent known formally as "the robustness principle", also known
informally as "Postel's Law": "Be liberal in what you accept, and
conservative in what you send" [RFC1122].
Jon Postel's directive is often interpreted to mean that any deviance from a specification is acceptable. However, we believe it was intended only to account for legitimate variations in interpretation within specifications, as well as basic transit errors, like bit errors. Taken to its unintended extreme, excessive tolerance would imply that there are no limits to the liberties that a sender might take, while presuming a burden on a receiver to guess "correctly" at the meaning of any such variation. These matters are further compounded by receiver software -- the end users' mail readers -- which are also sometimes flawed, leaving senders to craft messages (sometimes bending the rules) to overcome those flaws.
Jon Postelの指令は、仕様からの逸脱が許容されることを意味するとしばしば解釈されます。ただし、仕様内の解釈における正当なばらつきや、ビットエラーなどの基本的な転送エラーのみを説明することを目的としたものと考えています。意図しない極端な場合、過度の許容度は、送信者がとる可能性のある自由に制限がないことを意味しますが、そのような変動の意味を「正しく」推測するための受信者の負担を推定します。これらの問題は、受信者ソフトウェア（エンドユーザーのメールリーダー）によってさらに悪化します。これも時々欠陥があり、送信者がそれらの欠陥を克服するためにメッセージを作成する（時にはルールを曲げる）ようにします。
In general, this served the email ecosystem well by allowing a few errors in implementations without obstructing participation in the game. The proverbial bar was set low. However, as we have evolved into the current era, some of these lenient stances have begun to expose opportunities that can be exploited by malefactors. Various email-based applications rely on the strong application of these standards for simple security checks, while the very basic building blocks of that infrastructure, intending to be robust, fail utterly to assert those standards.
一般に、これは、ゲームへの参加を妨げることなく実装でいくつかのエラーを許可することにより、電子メールエコシステムに役立ちました。ことわざは低く設定されました。しかし、私たちが現在の時代に進化するにつれて、これらの寛大なスタンスのいくつかは、悪意のある者が利用できる機会を露呈し始めています。さまざまな電子メールベースのアプリケーションは、単純なセキュリティチェックのためにこれらの標準の強力なアプリケーションに依存していますが、そのインフラストラクチャの非常に基本的なビルディングブロックは、堅牢であることを目的としているため、これらの標準をまったく主張できません。
The distributed and non-interactive nature of email has often prompted adjustments to receiving software, to handle these variations, rather than trying to gain better conformance by senders, since the receiving operator is primarily driven by complaints from recipient users and has no authority over the sending side of the system. Processing with such flexibility comes at some cost, since mail software is faced with decisions about whether to permit non-conforming messages to continue toward their destinations unaltered, adjust them to conform (possibly at the cost of losing some of the original message), or reject them outright.
受信オペレーターは主に受信者ユーザーからの苦情によって動かされ、送信者に対する権限を持たないため、電子メールの分散型で非インタラクティブな性質により、送信者によるより良い適合を得ようとするのではなく、受信ソフトウェアを調整してこれらのバリエーションを処理することがよくあります。システムの送信側。メールソフトウェアは、不適合メッセージを変更せずに宛先に向けて続行できるようにするか、適合できるように調整するか（おそらく元のメッセージの一部が失われるという犠牲を払って）、またはそれらを完全に拒否します。
This document includes a collection of the best advice available regarding a variety of common malformed mail situations; it is to be used as implementation guidance. These malformations are typically based around loose interpretations or implementations of specifications such as the Internet Message Format [MAIL] and Multipurpose Internet Mail Extensions [MIME].
このドキュメントには、さまざまな一般的な不正メールの状況に関して利用可能な最良のアドバイスのコレクションが含まれています。実装ガイダンスとして使用されます。これらの奇形は通常、インターネットメッセージフォーマット[メール]や多目的インターネットメール拡張[MIME]などの仕様の緩やかな解釈または実装に基づいています。
It is important to understand that this work is not an effort to endorse or standardize certain common malformations. The code and culture that introduces such messages into the mail stream needs to be repaired, as the security penalty now being paid for this lax processing arguably outweighs the reduction in support costs to end users who are not expected to understand the standards. However, the reality is that this will not be fixed quickly.
この作業は、特定の一般的な奇形を承認または標準化するための取り組みではないことを理解することが重要です。そのようなメッセージをメールストリームに導入するコードとカルチャーは修復する必要があります。現在、この緩やかな処理に対して支払われるセキュリティペナルティは、標準を理解することを期待されていないエンドユーザーへのサポートコストの削減を上回っています。ただし、これはすぐには修正されないのが現実です。
Given this, it is beneficial to provide implementers with guidance about the safest or most effective way to handle malformed messages when they arrive, taking into consideration the trade-offs of the choices available especially with respect to how various actors in the email ecosystem respond to such messages in terms of handling, parsing, or rendering to end users.
このため、特に電子メールエコシステムのさまざまなアクターがどのように応答するかに関して利用可能な選択のトレードオフを考慮して、到着時に不正なメッセージを処理する最も安全または最も効果的な方法に関するガイダンスを実装者に提供することは有益です。エンドユーザーへの処理、解析、またはレンダリングの面でこのようなメッセージ。
Many deviations from message format standards are considered by some receivers to be strong indications that the message is undesirable, such as spam or something containing malware. These receivers quickly decide that the best handling choice is simply to reject or discard the message. This means malformations caused by innocent misunderstandings or ignorance of proper syntax can cause messages with no ill intent also to fail to be delivered.
受信者によっては、メッセージ形式の標準からの多くの逸脱が、スパムやマルウェアを含む何かなど、メッセージが望ましくないことを示す強力な兆候であると見なされています。これらの受信者は、最良の処理の選択は単にメッセージを拒否または破棄することであるとすぐに判断します。これは、無実の誤解または適切な構文の無知によって引き起こされた奇形が、配信の失敗にもつながることを意味します。
Senders that want to ensure message delivery are best advised to adhere strictly to the relevant standards (including, but not limited to, [MAIL], [MIME], and [DKIM]), as well as observe other industry best practices such as may be published from time to time by either the IETF or independently.
メッセージの配信を確実にしたい送信者は、関連する標準（[MAIL]、[MIME]、および[DKIM]を含むがこれらに限定されない）に厳密に従うこと、およびその他の業界のベストプラクティスを遵守することをお勧めします。 IETFによって、または独立して時々公開されます。
Receivers that haven't the luxury of strict enforcement of the standards on inbound messages are usually best served by observing the following guidelines for handling of malformed messages:
受信メッセージの標準を厳密に適用する余裕がない受信者は、通常、不正な形式のメッセージを処理するための次のガイドラインを遵守することで最善のサービスを提供できます。
1. Whenever possible, mitigation of syntactic malformations should be guided by an assessment of the most likely semantic intent. For example, it is reasonable to conclude that multiple sets of angle brackets around an address are simply superfluous and can be dropped.
1. 可能な限り、構文の奇形の緩和は、最も可能性の高い意味的意図の評価によって導かれるべきです。たとえば、アドレスを囲む複数の山かっこのセットは単に不要であり、削除できると結論付けるのが妥当です。
2. When the intent is unclear, or when it is clear but also impractical to change the content to reflect that intent, mitigation should be limited to cases where not taking any corrective action would clearly lead to a worse outcome.
2. 意図が不明確な場合、または明確であるがその意図を反映するようにコンテンツを変更することが非現実的である場合、緩和策は、是正措置を講じないことが明らかに悪い結果につながる場合に限定する必要があります。
3. Security issues, when present, need to be addressed and may force mitigation strategies that are otherwise suboptimal.
3. セキュリティの問題が存在する場合は、対処する必要があり、そうでなければ最適ではない緩和戦略を強制する可能性があります。
Examples of message content include a number within braces at the end of each line. These are line numbers for use in subsequent discussion, and they are not actually part of the message content presented in the example.
メッセージの内容の例には、各行の終わりにある中括弧内の数字が含まれます。これらは、以降の説明で使用するための行番号であり、実際に例に示されているメッセージコンテンツの一部ではありません。
Blank lines are not numbered in the examples.
例では、空白行には番号が付けられていません。
The reader would benefit from reading [EMAIL-ARCH] for some general background about the overall email architecture. Of particular interest is the Internet Message Format, detailed in [MAIL]. Throughout this document, the use of the term "message" should be assumed to mean a block of text conforming to the Internet Message Format.
読者は、電子メールアーキテクチャ全体に関する一般的な背景について[EMAIL-ARCH]を読むことでメリットを得られます。特に興味深いのは、[MAIL]で詳述されているインターネットメッセージフォーマットです。このドキュメント全体を通して、「メッセージ」という用語の使用は、インターネットメッセージフォーマットに準拠したテキストのブロックを意味すると想定されるべきです。
An agent handling a message could use several distinct representations of the message. One is an internal representation, such as separate blocks of storage for the header and body, some header or body alterations, or tables indexed by header name, set up to make particular kinds of processing easier. The other is the representation passed along to the next agent in the handling chain. This might be identical to the message input to the module, or it might have some changes such as added or reordered header fields or body elisions to remove malicious content.
メッセージを処理するエージェントは、メッセージのいくつかの異なる表現を使用できます。 1つは内部表現です。たとえば、ヘッダーと本文の個別のストレージブロック、一部のヘッダーまたは本文の変更、またはヘッダー名でインデックスが付けられたテーブルなど、特定の種類の処理を容易にするために設定されます。もう1つは、処理チェーンの次のエージェントに渡される表現です。これは、モジュールへのメッセージ入力と同じである場合や、ヘッダーフィールドの追加や並べ替え、悪意のあるコンテンツを削除するための本文の省略など、いくつかの変更がある場合があります。
Message handling is usually most effective when each in a sequence of handling modules receives the same content for analysis. A module that "fixes" or otherwise alters the content passed to later modules can prevent the later modules from identifying malicious or other content that exposes the end user to harm. It is important that all processing modules can make consistent assertions about the content. Modules that operate sequentially sometimes add private header fields to relay information downstream for later filters to use (and possibly remove), or they may have out-of-band ways of doing so. However, even the presence of private header fields can impact a downstream handling agent unaware of its local semantics, so an out-of-band method is always preferable.
メッセージ処理は通常、一連の処理モジュールのそれぞれが分析のために同じコンテンツを受信するときに最も効果的です。後のモジュールに渡されるコンテンツを「修正」または変更するモジュールは、後のモジュールがエンドユーザーに危害を及ぼす可能性のある悪意のあるコンテンツやその他のコンテンツを識別できないようにすることができます。すべての処理モジュールがコンテンツについて一貫したアサーションを作成できることが重要です。順次動作するモジュールは、プライベートヘッダーフィールドを追加して下流の情報を中継し、後のフィルターで使用（場合によっては削除）できるようにするか、帯域外の方法で実行する場合があります。ただし、プライベートヘッダーフィールドが存在する場合でも、ローカルのセマンティクスを認識しないダウンストリーム処理エージェントに影響を与える可能性があるため、アウトオブバンド方式が常に推奨されます。
The above is less of a concern when multiple analysis modules are operated in parallel, independent of one another.
複数の分析モジュールが互いに独立して並行して操作される場合、上記はそれほど問題ではありません。
Often, abuse reporting systems can act effectively only when a complaint or report contains the original message exactly as it was generated. Messages that have been altered by handling modules might render a complaint not actionable as the system receiving the report may be unable to identify the original message as one of its own.
多くの場合、乱用報告システムは、苦情または報告に元のメッセージが生成されたとおりに含まれている場合にのみ効果的に機能します。モジュールを処理することによって変更されたメッセージは、レポートを受信するシステムが元のメッセージを独自のメッセージの1つとして識別できない場合があるため、苦情を処理できない場合があります。
Some message changes alter syntax without changing semantics. For example, Section 7.4 describes a situation where an agent removes additional header whitespace. This is a syntax change without a change in semantics, though some systems (such as DKIM) are sensitive to such changes. Message system developers need to be aware of the downstream impact of making either kind of change.
一部のメッセージ変更は、セマンティクスを変更せずに構文を変更します。たとえば、セクション7.4では、エージェントが追加のヘッダーの空白を削除する状況について説明しています。これは、セマンティクスを変更しない構文の変更ですが、一部のシステム（DKIMなど）はそのような変更に敏感です。メッセージシステムの開発者は、いずれかの種類の変更を行うことによる下流への影響を認識する必要があります。
Where a change to content between modules is unavoidable, it is a good idea to add standard trace data to indicate a "visible" handoff between modules has occurred. The only advisable way to do this is to prepend Received fields with the appropriate information, as described in Section 3.6.7 of [MAIL].
モジュール間のコンテンツの変更が避けられない場合は、標準のトレースデータを追加して、モジュール間で「目に見える」ハンドオフが発生したことを示すことをお勧めします。これを行う唯一の賢明な方法は、[MAIL]のセクション3.6.7で説明されているように、適切な情報を受信フィールドに付加することです。
There will always be local handling exceptions, but these guidelines should be useful for developing integrated message processing environments.
ローカル処理の例外は常に存在しますが、これらのガイドラインは統合メッセージ処理環境の開発に役立つはずです。
In most cases, this document only discusses techniques used on internal representations. It is occasionally necessary to make changes between the input and output versions; such cases will be called out explicitly.
ほとんどの場合、このドキュメントでは内部表現で使用される手法についてのみ説明します。入力バージョンと出力バージョンの間で変更を行う必要がある場合があります。そのような場合は明示的に呼び出されます。
Within the email context, the single most influential component that can reduce the presence of malformed items in the email system is the Mail Handling Service (MHS; see [EMAIL-ARCH]), which includes the Mail Submission Agent (MSA). This is the component that is essentially the interface between end users that create content and the mail stream.
電子メールのコンテキスト内で、電子メールシステム内の不正なアイテムの存在を減らすことができる最も影響力のあるコンポーネントは、Mail Submission Agent（MSA）を含むメール処理サービス（MHS; [EMAIL-ARCH]を参照）です。これは基本的に、コンテンツを作成するエンドユーザーとメールストリーム間のインターフェースであるコンポーネントです。
MHSs need to become more strict about enforcement of all relevant email standards, especially [MAIL] and the [MIME] family of documents.
MHSは、関連するすべての電子メール標準、特に[MAIL]および[MIME]ファミリのドキュメントの施行について、より厳格になる必要があります。
More strict conformance by relaying Mail Transfer Agents (MTAs) will also be helpful. Although preventing the dissemination of malformed messages is desirable, the rejection of such mail already in transit also has a support cost -- namely, the creation of a [DSN] that many end users might not understand.
Mail Transfer Agent（MTA）をリレーすることによるより厳密な適合も役立ちます。不正な形式のメッセージの流布を防ぐことは望ましいですが、すでに転送中のそのようなメールを拒否することにもサポートコストがかかります。つまり、多くのエンドユーザーが理解できない[DSN]の作成です。
For interoperable Internet Mail messages, the only valid line separation sequence during a typical SMTP session is ASCII 0x0D ("carriage return", or CR) followed by ASCII 0x0A ("line feed", or LF), commonly referred to as "CRLF". This is not the case for binary mode SMTP (see [BINARYSMTP]).
相互運用可能なインターネットメールメッセージの場合、通常のSMTPセッション中の有効な行区切りシーケンスは、ASCII 0x0D（「復帰」またはCR）とそれに続くASCII 0x0A（「ラインフィード」またはLF）で、通常は「CRLF」と呼ばれます。 。これは、バイナリモードのSMTPには当てはまりません（[BINARYSMTP]を参照）。
Common UNIX user tools, however, typically only use LF for internal line termination. This means that a protocol engine that converts between UNIX and Internet message formats has to convert between these two end-of-line representations before transmitting a message or after receiving it.
ただし、一般的なUNIXユーザーツールでは、通常、LFは内部回線終端にのみ使用されます。つまり、UNIXとインターネットのメッセージ形式間で変換するプロトコルエンジンは、メッセージを送信する前または受信した後で、これら2つの行末表現の間で変換する必要があります。
Non-compliant implementations can create messages with a mix of line terminations, such as LF everywhere except CRLF only at the end of the message. According to [SMTP] and [MAIL], this means the entire message actually exists on a single line.
非準拠の実装では、メッセージの最後にのみCRLFを除くすべての場所でLFなどの行終端が混在するメッセージを作成できます。 [SMTP]と[MAIL]によれば、これはメッセージ全体が実際には1行に存在することを意味します。
Within modern Internet Mail, it is highly unlikely that an isolated CR or LF is valid in common ASCII text. Furthermore, when content actually does need to contain such an unusual character sequence, [MIME] provides mechanisms for encoding that content in an SMTP-safe manner.
最近のインターネットメールでは、分離されたCRまたはLFが一般的なASCIIテキストで有効である可能性はほとんどありません。さらに、コンテンツがそのような異常な文字シーケンスを実際に含む必要がある場合、[MIME]はそのコンテンツをSMTPセーフな方法でエンコードするメカニズムを提供します。
Thus, it will typically be safe and helpful to treat an isolated CR or LF as equivalent to a CRLF when parsing a message.
したがって、メッセージを解析するときは、通常、隔離されたCRまたはLFをCRLFと同等に扱うことが安全で役立ちます。
Note that this advice pertains only to the raw SMTP data and not to decoded MIME entities. As noted above, when MIME encoding mechanisms are used, the unusual character sequences are not visible in the raw SMTP stream.
このアドバイスは生のSMTPデータにのみ関係し、デコードされたMIMEエンティティには関係しないことに注意してください。上記のように、MIMEエンコードメカニズムが使用される場合、異常な文字シーケンスは生のSMTPストリームに表示されません。
This section covers common syntactic and semantic anomalies found in a message header and presents suggested methods of mitigation.
このセクションでは、メッセージヘッダーに見られる一般的な構文および意味の異常について説明し、推奨される軽減方法を示します。
A message using an obsolete header syntax (see Section 4 of [MAIL]) might confound an agent that is attempting to be robust in its handling of syntax variations. A bad actor could exploit such a weakness in order to get abusive or malicious content through a filter. This section presents some examples of such variations. Messages including these variations ought to be rejected; where this is not possible, recommended internal interpretations are provided.
廃止されたヘッダー構文を使用するメッセージ（[MAIL]のセクション4を参照）は、構文のバリエーションの処理を堅牢にしようとしているエージェントを混乱させる可能性があります。悪意のある俳優は、フィルタを介して虐待的または悪意のあるコンテンツを入手するために、このような弱点を悪用する可能性があります。このセクションでは、そのようなバリエーションのいくつかの例を示します。これらのバリエーションを含むメッセージは拒否されるべきです。これが不可能な場合は、推奨される内部解釈が提供されます。
The following obsolete syntax attempts to specify source routing:
次の古い構文は、ソースルーティングを指定しようとしています。
To: <@example.net:fran@example.com>
This means "send to fran@example.com via the mail service at example.net". It can safely be interpreted as:
これは、「example.netのメールサービスを介してfran@example.comに送信する」ことを意味します。安全に次のように解釈できます。
To: <fran@example.com>
The following overuse of angle brackets:
山かっこの次の過剰使用：
To: <<<user2@example.org>>>
can safely be interpreted as:
安全に次のように解釈できます。
To: <user2@example.org>
The following use of unbalanced angle brackets:
アンバランス山かっこの次の使用：
To: <another@example.net
can usually be treated as:
通常、次のように扱うことができます。
To: <another@example.net>
The following:
以下：
To: second@example.org>
can usually be treated as:
通常、次のように扱うことができます。
To: second@example.org
と： せこんｄ＠えぁｍｐぇ。おｒｇ
The following use of unbalanced parentheses:
次のように括弧を使用しない：
To: (Testing <fran@example.com>
can safely be interpreted as:
安全に次のように解釈できます。
To: (Testing) <fran@example.com>
Likewise, this case:
同様に、この場合：
To: Testing) <sam@example.com>
can safely be interpreted as:
安全に次のように解釈できます。
To: "Testing)" <sam@example.com>
In both cases, it is obvious where the active email address in the string can be found. The former case retains the active email address in the string by completing what appears to be intended as a comment; the intent in the latter case is less obvious, so the leading string is interpreted as a display name.
どちらの場合も、文字列内のアクティブな電子メールアドレスがどこにあるかは明らかです。前者のケースは、コメントとして意図されているように見えるものを完成させることによって、文字列内のアクティブな電子メールアドレスを保持します。後者の場合の意図は明確ではないため、先頭の文字列は表示名として解釈されます。
This use of an errant comma:
この誤ったコンマの使用：
To: <third@example.net, fourth@example.net>
can usually be interpreted as ending an address, so the above is usually best interpreted as:
通常、アドレスの終了と解釈できるため、上記は通常次のように解釈するのが最適です。
To: third@example.net, fourth@example.net
The following use of unbalanced quotation marks:
不均衡な引用符の次の使用：
To: "Joe <joe@example.com>
leaves software with no unambiguous interpretation. One possible interpretation is:
明確な解釈のないソフトウェアを残します。考えられる解釈の1つは次のとおりです。
To: "Joe <joe@example.com>"@example.net
where "example.net" is the domain name or host name of the handling agent making the interpretation. However, the more obvious and likely best interpretation is simply:
ここで、「example.net」は、解釈を行う処理エージェントのドメイン名またはホスト名です。ただし、より明確であり、最も可能性の高い最良の解釈は次のとおりです。
To: "Joe" <joe@example.com>
[MAIL] defines a local-part as the user portion of an email address, and the display-name as the "user-friendly" label that accompanies the address specification.
[メール]は、ローカル部分をメールアドレスのユーザー部分として定義し、表示名をアドレス指定に付随する「ユーザーフレンドリー」なラベルとして定義します。
Some broken submission agents might introduce messages with only a local-part or only a display-name and no properly formed address. For example:
一部の壊れた送信エージェントは、ローカル部分のみまたは表示名のみを含み、正しい形式のアドレスを持たないメッセージを導入する場合があります。例えば：
To: Joe
と： じょえ
A submission agent ought to reject this or, at a minimum, append "@" followed by its own host name or some other valid name likely to enable a reply to be delivered to the correct mailbox. Where this is not done, an agent receiving such a message will probably be successful by synthesizing a valid header field for evaluation using the techniques described in Section 7.5.2.
送信エージェントはこれを拒否するか、少なくとも「@」の後に独自のホスト名または他の有効な名前を追加して、正しいメールボックスに返信を配信できるようにする必要があります。これが行われていない場合、そのようなメッセージを受信するエージェントは、セクション7.5.2で説明されている手法を使用して評価用の有効なヘッダーフィールドを合成することでおそらく成功します。
Some messages contain a line of text in the header that is not a valid message header field of any kind. For example:
一部のメッセージのヘッダーには、有効なメッセージヘッダーフィールドではないテキスト行が含まれています。例えば：
From: user@example.com {1}
To: userpal@example.net {2}
Subject: This is your reminder {3}
about the football game tonight {4}
Date: Wed, 20 Oct 2010 20:53:35 -0400 {5}
Don't forget to meet us for the tailgate party! {7}
The cause of this is typically a bug in a message generator of some kind. Line {4} was intended to be a continuation of line {3}; it should have been indented by whitespace as set out in Section 2.2.3 of [MAIL].
この原因は通常、何らかのメッセージジェネレーターのバグです。行{4}は行{3}の続きになるように意図されていました。 [MAIL]のセクション2.2.3で説明されているように、空白でインデントされているはずです。
This anomaly has varying impacts on processing software, depending on the implementation:
この異常は、実装に応じて、処理ソフトウェアにさまざまな影響を及ぼします。
1. Some agents choose to separate the header of the message from the body only at the first empty line (that is, a CRLF immediately followed by another CRLF).
1. 一部のエージェントは、最初の空の行（つまり、CRLFの直後に別のCRLFが続く）でのみメッセージのヘッダーを本文から分離することを選択します。
2. Some agents assume this anomaly should be interpreted to mean the body starts at line {4}, as the end of the header is assumed by encountering something that is not a valid header field or folded portion thereof.
2. 一部のエージェントは、この異常を本文が{4}行目から始まると解釈する必要があると想定しています。ヘッダーの終わりは、有効なヘッダーフィールドまたはその折り返し部分ではないものに遭遇することによって想定されるためです。
3. Some agents assume this should be interpreted as an intended header folding as described above and thus simply append a single space character (ASCII 0x20) and the content of line {4} to that of line {3}.
3. 一部のエージェントは、これを上記のように意図したヘッダーの折りたたみとして解釈する必要があると想定し、単一のスペース文字（ASCII 0x20）と行{4}の内容を行{3}の内容に単に追加します。
4. Some agents reject this outright as line {4} is neither a valid header field nor a folded continuation of a header field prior to an empty line.
4. 行{4}は有効なヘッダーフィールドでも、空の行の前のヘッダーフィールドの折り返しの続きでもないため、一部のエージェントはこれを完全に拒否します。
This can be exploited if it is known that one message handling agent will take one action, while the next agent in the handling chain will take another. Consider, for example, a message filter that searches message headers for properties indicative of abusive or malicious content that is attached to a Mail Transfer Agent (MTA) implementing option 2 above. An attacker could craft a message that includes this malformation at a position above the property of interest, knowing the MTA will not consider that content part of the header. Consequently, the MTA will not feed it to the filter; thus, it avoids detection. Meanwhile, the Mail User Agent (MUA), which presents the content to an end user, implements option 1 or 3, which has some undesirable effect.
これは、1つのメッセージ処理エージェントが1つのアクションを実行し、処理チェーン内の次のエージェントが別のアクションを実行することがわかっている場合に利用できます。たとえば、上記のオプション2を実装するメール転送エージェント（MTA）に添付されている悪意のあるコンテンツまたは悪意のあるコンテンツを示すプロパティのメッセージヘッダーを検索するメッセージフィルターについて考えてみます。攻撃者は、MTAがヘッダーのコンテンツ部分を考慮しないことを知っていて、対象のプロパティの上の位置にこの奇形を含むメッセージを作成する可能性があります。したがって、MTAはそれをフィルターに供給しません。したがって、検出が回避されます。一方、エンドユーザーにコンテンツを提示するメールユーザーエージェント（MUA）は、オプション1または3を実装しています。
It should be noted that a few implementations choose option 4 above since any reputable message generation program will get header folding right, and thus anything so blatant as this malformation is likely an error caused by a malefactor.
信頼できるメッセージ生成プログラムはヘッダーの折りたたみを正しく行うため、いくつかの実装では上記のオプション4を選択します。したがって、この奇形は悪意のある者が原因のエラーである可能性が高いため、露骨なものはすべて含まれます。
The preferred implementation if option 4 above is not employed is to apply the following heuristic when this malformation is detected:
上記のオプション4を使用しない場合の好ましい実装は、この奇形が検出されたときに次のヒューリスティックを適用することです。
1. Search forward for an empty line. If one is found, then apply option 3 above to the anomalous line, and continue.
1. 空の行を前方に検索します。見つかった場合は、上記のオプション3を異常なラインに適用して続行します。
2. Search forward for another line that appears to be a new header field (a name followed by a colon). If one is found, then apply option 3 above to the anomalous line, and continue.
2. 新しいヘッダーフィールド（名前の後にコロンが続く）のように見える別の行を前方に検索します。見つかった場合は、上記のオプション3を異常なラインに適用して続行します。
The following message is valid per [MAIL]:
次のメッセージは[MAIL]ごとに有効です。
From: user@example.com {1}
To: userpal@example.net {2}
Subject: This is your reminder {3}
{4}
about the football game tonight {5}
Date: Wed, 20 Oct 2010 20:53:35 -0400 {6}
Don't forget to meet us for the tailgate party! {8}
Line {4} contains a single whitespace. The intended result is that lines {3}, {4}, and {5} comprise a single continued header field. However, some agents are aggressive at stripping trailing whitespace, which will cause line {4} to be treated as an empty line, and thus the separator line between header and body. This can affect header-specific processing algorithms as described in the previous section.
行{4}には単一の空白が含まれています。意図した結果は、行{3}、{4}、および{5}が単一の継続ヘッダーフィールドを構成することです。ただし、一部のエージェントは、末尾の空白を取り除くことに積極的であり、これにより、行{4}が空の行として扱われ、ヘッダーと本文の間の区切り線が扱われます。これは、前のセクションで説明したように、ヘッダー固有の処理アルゴリズムに影響を与える可能性があります。
This example was legal in earlier versions of the Internet message format standard but was rendered obsolete as of [RFC2822] as line {4} could be interpreted as the separator between the header and body.
この例は、インターネットメッセージフォーマット標準の以前のバージョンでは合法でしたが、[RFC2822]の時点で廃止されました。行{4}はヘッダーと本文の間の区切り文字として解釈される可能性があるためです。
The best handling of this example is for a message parsing engine to behave as if line {4} were not present in the message and for a message creation engine to emit the message with line {4} removed.
この例の最良の処理は、メッセージ解析エンジンが行{4}がメッセージに存在しないかのように動作し、メッセージ作成エンジンが行{4}が削除されたメッセージを出力することです。
Among the many possible malformations, a common one is insertion of whitespace at unusual locations, such as:
考えられる多くの奇形のうち、一般的なものは、次のような異常な場所での空白の挿入です。
From: user@example.com {1}
To: userpal@example.net {2}
Subject: This is your reminder {3}
MIME-Version : 1.0 {4}
Content-Type: text/plain {5}
Date: Wed, 20 Oct 2010 20:53:35 -0400 {6}
Don't forget to meet us for the tailgate party! {8}
Note the addition of whitespace in line {4} after the header field name but before the colon that separates the name from the value.
ヘッダーフィールド名の後、名前と値を区切るコロンの前の行{4}に空白が追加されていることに注意してください。
The obsolete grammar of Section 4 of [MAIL] permits that extra whitespace, so it cannot be considered invalid. However, a consensus of implementations prefers to remove that whitespace. There is no perceived change to the semantics of the header field being altered as the whitespace is itself semantically meaningless. Therefore, it is best to remove all whitespace after the field name but before the colon and to emit the field in this modified form.
[MAIL]のセクション4の古い文法では、余分な空白を許可しているため、無効と見なすことはできません。ただし、実装のコンセンサスでは、その空白を削除することを好みます。空白自体は意味的に無意味であるため、変更されるヘッダーフィールドのセマンティクスに認識される変更はありません。したがって、フィールド名の後、コロンの前のすべての空白を削除し、この変更された形式でフィールドを出力するのが最善です。
Section 3.6 of [MAIL] prescribes specific header field counts for a valid message. Few agents actually enforce these in the sense that a message whose header contents exceed one or more limits set there are generally allowed to pass; they typically add any required fields that are missing, however.
[MAIL]のセクション3.6は、有効なメッセージの特定のヘッダーフィールド数を規定しています。ヘッダーの内容が設定された1つ以上の制限を超えるメッセージは一般に通過が許可されるという意味で、実際にこれらを強制するエージェントはほとんどありません。ただし、通常は欠落している必須フィールドを追加します。
Also, few agents that use messages as input, including MUAs that actually display messages to users, verify that the input is valid before proceeding. Some popular open-source filtering programs and some popular Mailing List Management (MLM) packages select either the first or last instance of a particular field name, such as From, to decide who sent a message. Absent strict enforcement of [MAIL], an attacker can craft a message with multiple instances of the same fields if that attacker knows the filter will make a decision based on one, but the user will be shown the others.
また、実際にユーザーにメッセージを表示するMUAを含む、メッセージを入力として使用するいくつかのエージェントは、続行する前に入力が有効であることを確認します。一部の一般的なオープンソースフィルタリングプログラムと一部の一般的なメーリングリスト管理（MLM）パッケージは、送信者などの特定のフィールド名の最初または最後のインスタンスを選択して、メッセージの送信者を決定します。 [MAIL]が厳密に適用されていない場合、攻撃者はフィルタが1つに基づいて決定を行うことを攻撃者が知っていて、ユーザーには他のフィールドが表示される場合、同じフィールドの複数のインスタンスを使用してメッセージを作成できます。
This situation is exacerbated when message validity is assessed, such as through enhanced authentication methods like DomainKeys Identified Mail [DKIM]. Such methods might cover one instance of a constrained field but not another, taking the wrong one as "good" or "safe". An MUA, for example, could show the first of two From fields to an end user as "good" or "safe", while an authentication method actually only verified the second.
この状況は、DomainKeys Identified Mail [DKIM]などの拡張認証方式などによってメッセージの有効性が評価されると悪化します。そのようなメソッドは、制約されたフィールドの1つのインスタンスをカバーし、別のインスタンスをカバーしない可能性があります。間違ったインスタンスを「良好」または「安全」として扱います。たとえば、MUAは、2つのFromフィールドの最初のフィールドをエンドユーザーに「good」または「safe」として表示できますが、認証方法は実際には2番目のフィールドのみを検証しました。
In attempting to counter this exposure, one of the following strategies can be used:
この露出に対抗するために、次のいずれかの方法を使用できます。
1. reject outright or refuse to process further any input message that does not conform to Section 3.6 of [MAIL];
1. [MAIL]のセクション3.6に適合しない入力メッセージを完全に拒否するか、それ以上の処理を拒否する。
2. remove or, in the case of an MUA, refuse to render any instances of a header field whose presence exceeds a limit prescribed in Section 3.6 of [MAIL] when generating its output;
2. MUAの場合、その出力を生成するときに、その存在が[MAIL]のセクション3.6で規定されている制限を超えるヘッダーフィールドのインスタンスを削除するか、レンダリングすることを拒否します。
3. where a field can contain multiple distinct values (such as From) or is free-form text (such as Subject), combine them into a semantically identical, single header field of the same name (see Section 7.5.1);
3. フィールドに複数の異なる値（Fromなど）や自由形式のテキスト（Subjectなど）を含めることができる場合は、それらを組み合わせて、同じ名前の意味的に同一の単一ヘッダーフィールドにします（7.5.1を参照）。
4. alter the name of any header field whose presence exceeds a limit prescribed in Section 3.6 of [MAIL] when generating its output so that later agents can produce a consistent result. Any alteration likely to cause the field to be ignored by downstream agents is acceptable. A common approach is to prefix the field names with a string such as "BAD-".
4. 出力を生成するときに、その存在が[MAIL]のセクション3.6で規定された制限を超えるヘッダーフィールドの名前を変更して、後のエージェントが一貫した結果を生成できるようにします。下流のエージェントによってフィールドが無視される可能性が高い変更は許容されます。一般的なアプローチは、フィールド名の前に「BAD-」などの文字列を付けることです。
When selecting a mitigation action (or some other action) from the above list, an operator must consider its needs and the nature of its user base.
上記のリストから軽減アクション（またはその他のアクション）を選択する場合、オペレーターはそのニーズとユーザーベースの性質を考慮する必要があります。
There are some occasions where repeated fields are encountered where only one is expected. Two examples are presented. First:
繰り返しフィールドが1つしか期待されない場所で発生する場合があります。 2つの例を示します。最初：
From: reminders@example.com {1}
To: jqpublic@example.com {2}
Subject: Automatic Meeting Reminder {3}
Subject: 4pm Today -- Staff Meeting {4}
Date: Wed, 20 Oct 2010 08:00:00 -0700 {5}
Reminder of the staff meeting today in the small {6}
auditorium. Come early! {7}
The message above has two Subject fields, which is in violation of Section 3.6 of [MAIL]. A safe interpretation of this would be to treat it as though the two Subject field values were concatenated, so long as they are not identical, such as:
上記のメッセージには2つの[件名]フィールドがあり、[メール]のセクション3.6に違反しています。これを安全に解釈するには、次のように、2つのSubjectフィールド値が同一でない限り、連結されているかのように扱います。
From: reminders@example.com {1}
To: jqpublic@example.com {2}
Subject: Automatic Meeting Reminder {3}
4pm Today -- Staff Meeting {4}
Date: Wed, 20 Oct 2010 08:00:00 -0700 {5}
Reminder of the staff meeting today in the small {6}
auditorium. Come early! {7}
Second:
第二：
From: president@example.com {1}
From: vice-president@example.com {2}
To: jqpublic@example.com {3}
Subject: A note from the E-Team {4}
Date: Wed, 20 Oct 2010 08:00:00 -0700 {5}
This memo is to remind you of the corporate dress {6}
code. Attached you will find an updated copy of {7}
the policy. {8}
...
As with the first example, there is a violation in terms of the number of instances of the From field. A likely safe interpretation would be to combine these into a comma-separated address list in a single From field:
最初の例と同様に、[差出人]フィールドのインスタンス数に関して違反があります。おそらく安全な解釈は、これらを単一のFromフィールドのコンマ区切りアドレスリストに結合することです。
From: president@example.com, {1}
vice-president@example.com {2}
To: jqpublic@example.com {3}
Subject: A note from the E-Team {4}
Date: Wed, 20 Oct 2010 08:00:00 -0700 {5}
This memo is to remind you of the corporate dress {6}
code. Attached you will find an updated copy of {7}
the policy. {8}
...
Similar to the previous section, there are messages seen in the wild that lack certain required header fields. In particular, [MAIL] requires that a From and Date field be present in all messages.
前のセクションと同様に、必須のヘッダーフィールドが欠けているメッセージが実際に見られます。特に、[MAIL]では、すべてのメッセージにFromおよびDateフィールドが存在する必要があります。
When presented with a message lacking these fields, the MTA might perform one of the following:
これらのフィールドがないメッセージが表示された場合、MTAは次のいずれかを実行する可能性があります。
1. Make no changes.
1. 変更しないでください。
2. Add an instance of the missing field(s) using synthesized content based on data provided in other parts of the protocol.
2. プロトコルの他の部分で提供されるデータに基づいて合成されたコンテンツを使用して、欠落しているフィールドのインスタンスを追加します。
Option 2 is recommended for handling this case. Handling agents should add these for internal handling if they are missing, but should not add them to the external representation. The reason for this advice is that there are some filter modules that would consider the absence of such fields to be a condition warranting special treatment (for example, rejection), and thus the effectiveness of such modules would be stymied by an upstream filter adding them in a way visible to other components.
このケースを処理するには、オプション2をお勧めします。処理エージェントは、欠落している場合は内部処理のためにこれらを追加する必要がありますが、外部表現には追加しないでください。このアドバイスの理由は、そのようなフィールドの不在を特別な扱い（たとえば、拒否）を保証する条件と見なすいくつかのフィルターモジュールがあり、そのようなモジュールの有効性は、それらを追加する上流のフィルターによって妨げられるためです。他のコンポーネントから見える方法で。
The synthesized fields should contain a best guess as to what should have been there; for From, the SMTP MAIL command's address can be used (if not null) or a placeholder address followed by an address literal (for example, unknown@[192.0.2.1]); for Date, a date extracted from a Received field is a reasonable choice.
合成されたフィールドには、そこにあるはずだったものに関する最良の推測が含まれているはずです。 Fromには、SMTP MAILコマンドのアドレス（nullでない場合）またはアドレスリテラルが後に続くプレースホルダーアドレス（たとえば、unknown @ [192.0.2.1]）を使用できます。 Dateの場合、Receivedフィールドから抽出された日付が妥当な選択です。
One other important case to consider is a missing Message-ID field. An MTA that encounters a message missing this field should synthesize a valid one and add it to the external representation, since many deployed tools commonly use the content of that field as a unique message reference, so its absence inhibits correlation of message processing. Section 3.6.4 of [MAIL] describes advisable practice for synthesizing the content of this field when it is absent, and establishes a requirement that it be globally unique.
考慮すべきもう1つの重要なケースは、メッセージIDフィールドの欠落です。このフィールドがないメッセージに遭遇したMTAは、有効なメッセージを合成して外部表現に追加する必要があります。デプロイされたツールの多くは、そのフィールドの内容を一意のメッセージ参照として一般的に使用するため、メッセージが存在しないとメッセージ処理の相関が阻害されます。 [メール]のセクション3.6.4は、このフィールドがない場合にこのフィールドのコンテンツを合成するための推奨される方法を説明し、グローバルに一意であるという要件を確立します。
While legitimate messages can contain more than one Return-Path header field, such usage is often an error rather that a valid message containing multiple header field blocks as described in Sections 3.6 of [MAIL]. Accordingly, when a message containing multiple Return-Path header fields is encountered, all but the topmost one is to be disregarded, as it is most likely to have been added nearest to the mailbox that received that message.
正当なメッセージには複数のReturn-Pathヘッダーフィールドが含まれることがありますが、[MAIL]のセクション3.6で説明されているように、複数のヘッダーフィールドブロックを含む有効なメッセージではなく、そのような使用法は多くの場合エラーです。したがって、複数のReturn-Pathヘッダーフィールドを含むメッセージが検出された場合、そのメッセージを受信したメールボックスの最も近くに追加された可能性が最も高いため、最上位のもの以外はすべて無視されます。
MIME provides the means to include textual material employing character sets ("charsets") other than US-ASCII. Such material is required to have an identified charset. Charset identification is done using a "charset" parameter in the Content-Type header field, a charset label within the MIME entity itself, or the charset can be implicitly specified by the Content-Type (see [CHARSET]).
MIMEは、US-ASCII以外の文字セット（「charsets」）を使用するテキスト素材を含める手段を提供します。そのような資料は、識別された文字セットを持つ必要があります。文字セットの識別は、Content-Typeヘッダーフィールドの「charset」パラメータ、MIMEエンティティ自体内の文字セットラベルを使用して行われます。または、文字セットはContent-Typeで暗黙的に指定できます（[CHARSET]を参照）。
Unfortunately, it is fairly common for required character set information to be missing or incorrect in textual MIME entities. As such, processing agents should perform basic sanity checks, such as:
残念ながら、必要な文字セット情報がテキストMIMEエンティティで欠落しているか正しくないことはかなり一般的です。そのため、処理エージェントは次のような基本的な健全性チェックを実行する必要があります。
o US-ASCII contains bytes between 1 and 127 inclusive only (colloquially, "7-bit" data), so material including bytes outside of that range ("8-bit" data) is necessarily not US-ASCII. (See Section 2.1 of [MAIL].)
o US-ASCIIには1から127までのバイト（口語的には「7ビット」データ）のみが含まれるため、その範囲外のバイト（「8ビット」データ）を含む素材は必ずしもUS-ASCIIではありません。 （[MAIL]のセクション2.1を参照してください。）
o [UTF-8] has a very specific syntactic structure that other 8-bit charsets are unlikely to follow.
o [UTF-8]は、他の8ビット文字セットが従う可能性が非常に低い構文構造を持っています。
o Null bytes (ASCII 0x00) are not allowed in either 7-bit or 8-bit data.
o Nullバイト（ASCII 0x00）は、7ビットまたは8ビットのデータでは許可されていません。
o Not all 7-bit material is US-ASCII. The presence of the various escape sequences used for character switching can be used as an indication of the various charsets based on ISO/IEC 2022 [ISO-2022], such as those defined in [ISO-2022-CN], [ISO-2022-JP], and [ISO-2022-KR].
o すべての7ビット素材がUS-ASCIIであるとは限りません。文字切り替えに使用されるさまざまなエスケープシーケンスの存在は、[ISO-2022-CN]、[ISO-2022]で定義されているような、ISO / IEC 2022 [ISO-2022]に基づくさまざまな文字セットの指標として使用できます。 -JP]、[ISO-2022-KR]。
When a character set error is detected, processing agents should:
文字セットエラーが検出された場合、処理エージェントは次のことを行う必要があります。
1. apply heuristics to determine the most likely character set and, if successful, proceed using that information; or
1. ヒューリスティックを適用して最も可能性の高い文字セットを決定し、成功した場合はその情報を使用して続行します。または
2. refuse to process the malformed MIME entity.
2. 不正なMIMEエンティティの処理を拒否します。
A null byte inside a textual MIME entity can cause typical string processing functions to misidentify the end of a string, which can be exploited to hide malicious content from analysis processes. Accordingly, null bytes require additional special handling.
テキストMIMEエンティティ内のnullバイトは、典型的な文字列処理関数が文字列の終わりを誤認する原因となり、悪意のあるコンテンツを分析プロセスから隠すために悪用される可能性があります。したがって、nullバイトには追加の特別な処理が必要です。
A few null bytes in isolation is likely to be the result of poor message construction practices. Such nulls should be silently dropped.
分離されたいくつかのnullバイトは、メッセージの構築方法が不適切なために発生した可能性があります。そのようなヌルは、静かに削除されるべきです。
Large numbers of null bytes are usually the result of binary material that is improperly encoded, improperly labeled, or both. Such material is likely to be damaged beyond the hope of recovery, so the best course of action is to refuse to process it.
多数のnullバイトは通常、不適切にエンコードされた、不適切にラベル付けされた、またはその両方であるバイナリマテリアルの結果です。そのような材料は回復の希望を超えて損傷を受ける可能性が高いので、最善の行動方針はそれを処理することを拒否することです。
Finally, the presence of null bytes may be used as indication of possible malicious intent.
最後に、nullバイトの存在は、悪意のある可能性を示すものとして使用される可能性があります。
Standards-compliant email messages do not contain any non-ASCII data without indicating that such content is present by means of published SMTP extensions. Absent that, MIME encodings are typically used to convert non-ASCII data to ASCII in a way that can be reversed by other handling agents or end users.
標準に準拠した電子メールメッセージには、ASCII以外のデータは含まれていません。公開されたSMTP拡張機能によってそのようなコンテンツが存在することを示すものは含まれません。それがない場合、MIMEエンコーディングは通常、非ASCIIデータをASCIIに変換するために使用され、他の処理エージェントまたはエンドユーザーがそれを元に戻すことができます。
The best way to handle non-compliant 8-bit material depends on its location.
非準拠の8ビット素材を処理する最良の方法は、その場所によって異なります。
Non-compliant 8-bit material in MIME entity content should simply be processed as if the necessary SMTP extensions had been used to transfer the message. Note that improperly labeled 8-bit material in textual MIME entities may require treatment as described in Section 7.6.
MIMEエンティティコンテンツの非準拠の8ビットマテリアルは、必要なSMTP拡張機能がメッセージの転送に使用されたかのように処理するだけです。テキストのMIMEエンティティで不適切にラベル付けされた8ビットの素材は、セクション7.6で説明されているように処理が必要になる場合があります。
Non-compliant 8-bit material in message or MIME entity header fields can be handled as follows:
メッセージまたはMIMEエンティティヘッダーフィールドの非準拠の8ビットマテリアルは、次のように処理できます。
1. Occurrences in unstructured text fields, comments, and phrases can be converted into encoded-words (see [MIME3] if a likely character set can be determined). Alternatively, 8-bit characters can be removed or replaced with some other character.
1. 非構造化テキストフィールド、コメント、およびフレーズの出現は、エンコードされた単語に変換できます（可能性のある文字セットを特定できる場合は、[MIME3]を参照してください）。または、8ビット文字を削除するか、他の文字に置き換えることができます。
2. Occurrences in header fields whose syntax is unknown may be handled by dropping the field entirely or by removing/replacing the 8-bit character as described above.
2. 構文が不明なヘッダーフィールドでの発生は、フィールドを完全に削除するか、上記のように8ビット文字を削除/置換することで処理できます。
3. Occurrences in addresses are especially problematic. Agents supporting [EAI] may, if the 8-bit material conforms to 8-bit syntax, elect to treat the message as an EAI message and process it accordingly. Otherwise, in most cases, it is best to exclude the address from any sort of processing -- which may mean dropping it entirely -- since any attempt to fix it definitively is unlikely to be successful.
3. 住所の出現は特に問題です。 [EAI]をサポートするエージェントは、8ビットマテリアルが8ビット構文に準拠している場合、メッセージをEAIメッセージとして扱い、それに応じて処理することを選択できます。それ以外の場合は、ほとんどの場合、アドレスをすべての種類の処理から除外することをお勧めします。つまり、完全に削除することを意味する可能性があります。最終的にアドレスを修正しようとすると、成功する可能性は低いためです。
The five-part set of MIME specifications includes a mechanism of message extensions for providing text in character sets other than ASCII, non-text attachments to messages, multipart message bodies, and similar facilities.
5部構成のMIME仕様には、ASCII以外の文字セットでテキストを提供するためのメッセージ拡張のメカニズム、メッセージへの非テキスト添付、マルチパートメッセージ本文、および同様の機能が含まれます。
Some anomalies with MIME-compliant generation are also common. This section discusses some of those and presents preferred methods of mitigation.
MIME準拠の生成を伴ういくつかの異常も一般的です。このセクションでは、それらのいくつかについて説明し、軽減の好ましい方法を示します。
Any message that uses [MIME] constructs is required to have a MIME-Version header field. Without it, the Content-Type and associated fields have no semantic meaning.
[MIME]構造を使用するメッセージには、MIME-Versionヘッダーフィールドが必要です。それがなければ、Content-Typeと関連フィールドには意味的な意味がありません。
It is often observed that a message has complete MIME structure, yet lacks this header field. It is prudent to disregard this absence and conduct analysis of the message as if it were present, especially by agents attempting to identify malicious material.
メッセージは完全なMIME構造を持っていますが、このヘッダーフィールドが欠けていることがよくあります。特に悪意のある素材を特定しようとするエージェントによって、この不在を無視して、メッセージが存在するかのようにメッセージの分析を行うことは賢明です。
Further, the absence of MIME-Version might be an indication of malicious intent, and extra scrutiny of the message may be warranted. Such omissions are not expected from compliant message generators.
さらに、MIME-Versionが存在しないことは悪意があることを示している可能性があり、メッセージをさらに精査する必要がある場合があります。このような省略は、準拠メッセージジェネレーターでは想定されていません。
There have been a few different specifications of base64 in the past. The implementation defined in [MIME] instructs decoders to discard characters that are not part of the base64 alphabet. Other implementations consider an encoded body containing such characters to be completely invalid. Very early specifications of base64 (see [PEM89], for example, which was later obsoleted by [PEM93]) allowed email-style comments within base64-encoded data.
過去にbase64のいくつかの異なる仕様がありました。 [MIME]で定義された実装は、base64アルファベットの一部ではない文字を破棄するようデコーダーに指示します。他の実装では、そのような文字を含むエンコードされた本文は完全に無効であると見なします。 base64のごく初期の仕様（たとえば、[PEM89]を参照してください。後で[PEM93]で廃止されました）では、base64でエンコードされたデータ内で電子メール形式のコメントを使用できました。
The attack vector here involves constructing a base64 body whose meaning varies given different possible decodings. If a security analysis module wishes to be thorough, it should consider scanning the possible outputs of the known decoding dialects in an attempt to anticipate how the MUA will interpret the data.
ここでの攻撃ベクトルには、可能なデコードが異なると意味が異なるbase64本体の構築が含まれます。セキュリティ分析モジュールが徹底したい場合は、MUAがデータを解釈する方法を予測するために、既知のデコード方言の可能な出力をスキャンすることを検討する必要があります。
A message containing a line of content that exceeds 998 characters plus the line terminator (1000 total) violates Section 2.1.1 of [MAIL]. Some handling agents may not look at content in a single line past the first 998 bytes, providing bad actors an opportunity to hide malicious content.
998文字を超えるコンテンツ行と行末記号（合計1000）を含むメッセージは、[MAIL]のセクション2.1.1に違反しています。一部の処理エージェントは、最初の998バイトを超える1行のコンテンツを確認しない場合があり、悪意のあるコンテンツに悪意のあるコンテンツを隠す機会を提供します。
There is no specified way to handle such messages, other than to observe that they are non-compliant and reject them or rewrite the oversized line such that the message is compliant.
このようなメッセージを処理するための特定の方法はありません。メッセージが準拠していないことを確認して拒否するか、メッセージが準拠するように特大の行を書き換えます。
To ensure long lines do not prevent analysis of potentially malicious data, handling agents are strongly encouraged to take one of the following actions: 1. Break such lines into multiple lines at a position that does not change the semantics of the text being thus altered. For example, break an oversized line at a position such that a [URI] does not span two lines (which could inhibit the proper identification of the URI).
長い行が潜在的に悪意のあるデータの分析を妨げないように、処理エージェントは次のいずれかのアクションを実行することを強くお勧めします。1.このように変更されるテキストの意味を変更しない位置で、そのような行を複数行に分割します。たとえば、[URI]が2行にわたらないような位置で特大の行を分割します（これにより、URIの適切な識別が妨げられる可能性があります）。
2. Rewrite the MIME part (or the entire message if not MIME) that contains the excessively long line using a content encoding that breaks the line in the transmission but would still result in the line being intact on decoding for presentation to the user. Both of the encodings declared in [MIME] can accomplish this.
2. コンテンツのエンコードを使用して過度に長い行を含むMIME部分（またはMIMEでない場合はメッセージ全体）を書き換えて、伝送で行を分割しますが、ユーザーに提示するためのデコードで行はそのまま残ります。 [MIME]で宣言されている両方のエンコーディングでこれを実現できます。
The discussions of the anomalies above and their prescribed solutions are themselves security considerations. The practices enumerated in this document are generally perceived as attempts to resolve security considerations that already exist rather than introducing new ones. However, some of the attacks described here may not have appeared in previous email specifications.
上記の異常とその規定された解決策の説明は、それ自体がセキュリティの考慮事項です。このドキュメントに列挙されているプラクティスは、一般に、新しい考慮事項を導入するのではなく、すでに存在するセキュリティの考慮事項を解決する試みとして認識されています。ただし、ここで説明する攻撃の中には、以前の電子メールの仕様にはなかったものもあります。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[メールアーク]クロッカーD.、「インターネットメールアーキテクチャ」、RFC 5598、2009年7月。
[MAIL] Resnick, P., "Internet Message Format", RFC 5322, October 2008.
[メール] Resnick、P。、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part One：Format of Internet Message Bodies」、RFC 2045、1996年11月。
[BINARYSMTP] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large and Binary MIME Messages", RFC 3030, December 2000.
[BINARYSMTP] Vaudreuil、G。、「SMTP Service Extensions for Transmission of Large and Binary MIME Messages」、RFC 3030、2000年12月。
[CHARSET] Melnikov, A. and J. Reschke, "Update to MIME regarding "charset" Parameter Handling in Textual Media Types", RFC 6657, July 2012.
[CHARSET] Melnikov、A。およびJ. Reschke、「テキストメディアタイプの「charset」パラメータ処理に関するMIMEの更新」、RFC 6657、2012年7月。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, September 2011.
[DKIM] Crocker、D。、編、Hansen、T。、編、およびM. Kucherawy、編、「DomainKeys Identified Mail（DKIM）Signatures」、RFC 6376、2011年9月。
[DSN] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[DSN] Moore、K。およびG. Vaudreuil、「An Extensible Message Format for Delivery Status Notifications」、RFC 3464、2003年1月。
[EAI] Yang, A., Steele, S., and N. Freed, "Internationalized Email Headers", RFC 6532, February 2012.
[EAI] Yang、A.、Steele、S。、およびN. Freed、「Internationalized Email Headers」、RFC 6532、2012年2月。
[ISO-2022-CN] Zhu, HF., Hu, DY., Wang, ZG., Kao, TC., Chang, WCH., and M. Crispin, "Chinese Character Encoding for Internet Messages", RFC 1922, March 1996.
[ISO-2022-CN] Zhu、HF。、Hu、DY。、Wang、ZG。、Kao、TC。、Chang、WCH。、およびM. Crispin、「インターネットメッセージの漢字エンコーディング」、RFC 1922、3月1996。
[ISO-2022-JP] Murai, J., Crispin, M., and E. van der Poel, "Japanese Character Encoding for Internet Messages", RFC 1468, June 1993.
[ISO-2022-JP] Murai、J.、Crispin、M。、およびE. van der Poel、「インターネットメッセージの日本語文字エンコーディング」、RFC 1468、1993年6月。
[ISO-2022-KR] Choi, U., Chon, K., and H. Park, "Korean Character Encoding for Internet Messages", RFC 1557, December 1993.
[ISO-2022-KR] Choi、U.、Chon、K。、およびH. Park、「インターネットメッセージの韓国語文字エンコーディング」、RFC 1557、1993年12月。
[ISO-2022] ISO/IEC, "Information technology -- Character code structure and extension techniques", ISO/IEC 2022, 1994, <http://www.iso.org/iso/ catalogue_detail.htm?csnumber=22747>.
[ISO-2022] ISO / IEC、「情報技術-文字コード構造と拡張技術」、ISO / IEC 2022、1994、<http://www.iso.org/iso/ catalogue_detail.htm？csnumber = 22747> 。
[MIME3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[MIME3]ムーアK。、「MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのメッセージヘッダー拡張」、RFC 2047、1996年11月。
[PEM89] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I -- Message Encipherment and Authentication Procedures", RFC 1113, August 1989.
[PEM89] Linn、J.、「インターネット電子メールのプライバシー強化：パートI-メッセージの暗号化と認証手順」、RFC 1113、1989年8月。
[PEM93] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993.
[PEM93] Linn、J.、「インターネット電子メールのプライバシー強化：パートI：メッセージの暗号化と認証手順」、RFC 1421、1993年2月。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -- Communication Layers", RFC 1122, October 1989.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、RFC 1122、1989年10月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822] Resnick、P。、編、「インターネットメッセージ形式」、RFC 2822、2001年4月。
[RFC733] Crocker, D., Vittal, J., Pogran, K., and D. Henderson, Jr., "Standard for the Format of Internet Text Messages", RFC 733, November 1977.
[RFC733] Crocker、D.、Vittal、J.、Pogran、K。、およびD. Henderson、Jr。、「Standard for the Format for Internet Text Messages」、RFC 733、1977年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, January 2005.
[URI] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、RFC 3986、2005年1月。
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3629, 2003.
[UTF-8] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、RFC 3629、2003。
The authors wish to acknowledge the following for their review and constructive criticism of this proposal: Dave Cridland, Dave Crocker, Jim Galvin, Tony Hansen, John Levine, Franck Martin, Alexey Melnikov, and Timo Sirainen.
著者は、この提案に対するレビューと建設的な批評のために、Dave Cridland、Dave Crocker、Jim Galvin、Tony Hansen、John Levine、Franck Martin、Alexey Melnikov、Timo Sirainenを認めたいと思います。
Authors' Addresses
著者のアドレス
Murray S. Kucherawy
マレー・S・カーリー
EMail: superuser@gmail.com
Gregory N. Shapiro
Ｇれごｒｙ ん。 しゃぴろ
EMail: gshapiro@proofpoint.com
Ned Freed
ネッド・フリード
EMail: ned.freed@mrochek.com