Network Working Group K. Toyoda
Request for Comments: 3965 H. Ohno
Obsoletes: 2305 J. Murai
Category: Standards Track WIDE Project
D. Wing
Cisco
December 2004
A Simple Mode of Facsimile Using Internet Mail
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This specification provides for "simple mode" carriage of facsimile data using Internet mail. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols, Multipurpose Internet Mail Extensions (MIME), and Tagged Image File Format (TIFF) for Facsimile. It can send images not only to other Internet-aware facsimile devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Facsimile data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them.
この仕様は、インターネットメールを使用したファクシミリデータの「シンプルモード」のキャリッジのために用意されています。このドキュメントへの拡張が続きます。現在の仕様では、このようなTCP / IP、インターネット・メール・プロトコル、多目的インターネットメール拡張（MIME）、およびファクシミリのためのタグ付きイメージファイル形式（TIFF）などの標準プロトコルやファイルフォーマットを採用しています。これは、他のインターネット対応のファクシミリ装置に対してだけでなく、ファクシミリデータのMIMEメールやTIFFを扱うことができる一般的な電子メールの読者を持つPCなどのインターネット・ネイティブシステムにだけでなく、画像を送信することができます。仕様では、既存のファクシミリデバイス、インターネット・メール・エージェント、およびそれらを接続するゲートウェイ間の通信を容易にします。
This document is a revision of RFC 2305. There have been no technical changes.
このドキュメントは、技術的な変更はありませんRFC 2305の改訂版です。
This specification defines message-based facsimile communication over the Internet. It describes a minimum set of capabilities, taking into account those of typical facsimile devices and PCs that can generate facsimile data.
この仕様は、インターネットを介してメッセージベースのファクシミリ通信を定義します。それは考慮にファクシミリデータを生成することができ、典型的なファクシミリ機器とPCのそれを取って、機能の最小セットを記述する。
A G3Fax device has substantial restrictions due to specifications in the standards, such as for timers. This specification defines a profile for Internet mail, rather than creating a distinct "facsimile over the Internet" service. The semantics resulting from the profile are designed to be compatible with facsimile operation over the general switched telephone network, so that gateways between facsimile and Internet mail can operate with very high fidelity.
G3FAX装置は、タイマーのような標準で仕様による大幅な制約があります。この仕様は、むしろサービス「インターネット上でファクシミリ」明確なを作成するよりも、インターネットメールのプロファイルを定義します。プロファイルから得られる意味論は、一般交換電話網上ファクシミリ及びインターネットメールの間のゲートウェイが非常に高い忠実度で動作することができるように、ファクシミリ動作に適合するように設計されています。
The reason for developing this capability as an email profile is to permit interworking amongst facsimile and email users. For example, it is intended that existing email users be able to send normal messages to lists of users, including facsimile-based recipients, and that other email recipients shall be able to reply to the original and continue to include facsimile recipients. Similarly, it is intended that existing email software work without modification and not be required to process new, or different data structures, beyond what is normal for Internet mail users. Existing email service standards are used, rather than replicating mechanisms which are more tailored to existing facsimile standards, to ensure this compatibility with existing email service.
電子メールプロファイルとしてこの能力を開発するための理由は、ファクシミリ、電子メールユーザー間のインターワーキングを可能にすることです。例えば、既存の電子メールユーザーは、ファクシミリベースの受信者を含むユーザーのリストに通常のメッセージを送信することができること、および他の電子メール受信者が元に返信し、ファクシミリ受信者を含めるように続けることができるものとすることを意図しています。同様に、既存の電子メールソフトウェアの仕事修正なしとではないが、インターネットメールユーザーのための正常なものを超えて、新しい、または異なるデータ構造を処理するために必要とされることが意図されます。既存の電子メールサービス基準は、既存の電子メールサービスとのこの互換性を確保するために、むしろ既存のファクシミリ規格により適合しているメカニズムを複製するよりも、使用されています。
A facsimile-capable device that uses T.4 [15] and the general switched telephone network (GSTN) is called a "G3Fax device" in this specification. An "IFax device" is an Internet-accessible device capable of sending, receiving or forwarding Internet faxes. A message can be sent to an IFax device using an Internet mail address. A message can be sent to a G3Fax device using an Internet mail address; the message MAY be forwarded via an IFax offramp gateway.
T.4 [15]を使用し、一般交換電話網ファクシミリ可能なデバイス（GSTN）は、この明細書では「G3FAX装置」と呼ばれています。 「IFAX装置は、」インターネットFAXを送信、受信、または転送することが可能なインターネットアクセス可能な装置です。メッセージは、インターネットメールアドレスを使用してIFAXデバイスに送信することができます。メッセージは、インターネットメールアドレスを使用してG3FAX装置へ送信することができます。メッセージがIFAXのオフランプゲートウェイを介して転送されてもよいです。
This specification provides for communication between each of the following combinations:
この仕様は、以下の組み合わせのそれぞれとの間の通信を提供します。
Internet mail => Network printer Internet mail => Offramp gateway (forward to G3Fax) Network scanner => Network printer Network scanner => Offramp gateway (forward to G3Fax) Network scanner => Internet mail
インターネットメール=>ネットワークプリンタインターネットメール=>（フォワードG3FAXに）オフランプゲートウェイネットワークスキャナ=>ネットワークプリンタのネットワークスキャナ=>オフランプゲートウェイネットワークスキャナ（フォワードG3FAXへ）=>インターネットメール
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [13].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[13]に記載されているように解釈されます。
The set of conventions necessary to achieve facsimile-compatible service covers basic data transport, document data formats, message (document) addressing, delivery confirmation, and message security. In this section, the first 4 are covered. The remainder are covered in following sections, along with additional details for addressing and formats.
ファクシミリ互換サービスを達成するために必要な規則の組は、基本的なデータ転送、文書データのフォーマット、メッセージ（文書）アドレッシング、送達確認、およびメッセージのセキュリティをカバーします。このセクションでは、最初の4が被覆されています。残りは、アドレッシングおよびフォーマットの詳細と共に、以下のセクションで覆われています。
This section describes mechanisms involved in the transport between IFAX devices.
このセクションでは、IFAXデバイス間の輸送に関与するメカニズムを説明しています。
Data transfer MAY be achieved using standard Internet mail transfer mechanisms [1, 3]. The format of addresses MUST conform to the RFC 821 <addr-spec> and RFC 822 <mailbox> Internet mail standards [1, 2, 3].
データ転送は、標準的なインターネットメール転送機構[1、3]を使用して達成することができます。アドレスのフォーマットは、RFC 821 <ADDR仕様>に準拠し、RFC 822なければなりません<メールボックス>インターネットメール規格[1、2、3]。
A gateway translates between dissimilar environments. For IFax, a gateway connects between Internet mail and the T.4/GSTN facsimile. Gateways can service multiple T.4/GSTN facsimile users or can service only one. In the former case, they serve as a classic "mail transfer agent" (MTA) and in the latter as a classic "mail user agent" (UA). An onramp is a gateway which connects from T.4/GSTN facsimile to Internet mail. An offramp is a gateway which connects from Internet mail to T.4/GSTN facsimile. Behavior of onramps is out of scope for this specification.
ゲートウェイは、異なる環境間で変換します。 IFAXのために、ゲートウェイは、インターネットメールおよびT.4 / GSTNファクシミリとの間を接続します。ゲートウェイは、複数のT.4 / GSTNファックスユーザーにサービスを提供できるか一つだけにサービスを提供することができます。前者の場合、それらは古典的な「メール転送エージェント」（MTA）として、クラシック「メールユーザエージェント」（UA）、後者に役立ちます。オンランプは、インターネットメールにT.4 / GSTNファクシミリから接続するゲートウェイです。オフランプはT.4 / GSTNファクシミリ、インターネットメールから接続するゲートウェイです。 onrampsの挙動は、この仕様の範囲外です。
This specification describes the Internet mail service portion of offramp addressing, confirmation and failure notification. Details are provided in later sections.
この仕様は、インターネットメールサービスのアドレス指定オフランプの部分、確認および障害通知について説明します。詳細については、後のセクションで提供されています。
An offramp gateway that operate as an MTA serving multiple users SHOULD use SMTP; a gateway that operates as a UA serving a single mail recipient MAY use a mailbox access protocol such as POP [6] or similar mailbox access protocols.
複数のユーザにサービスを提供するMTAとして動作オフランプゲートウェイは、SMTPを使用する必要があります。単一のメール受信者にサービスを提供するUAとして動作するゲートウェイは、POPなどのメールボックスアクセスプロトコル[6]又は同様のメールボックスアクセスプロトコルを使用することができます。
NOTE: An offramp gateway that relays mail based on addressing information needs to ensure that it uses addresses supplied in the MTA envelope, rather than from elsewhere, such as addresses listed in the message content headers.
注：アドレス情報に基づいてメールを中継オフランプゲートウェイは、そのようなメッセージコンテンツヘッダーに記載されているアドレスとしてではなく他の場所からよりも、MTAのエンベロープに供給されるアドレスを使用していることを確認する必要があります。
IFax devices MUST be compliant with RFC 2822 and RFC 1123, which define the format of mail headers. The header of an IFax message SHOULD include Message-ID and MUST include all fields required by [2, 3], such as DATE and FROM.
IFAXデバイスは、メールヘッダのフォーマットを定義するRFC 2822及びRFC 1123に準拠しなければなりません。 IFAXのメッセージのヘッダは、メッセージIDを含むべきであり、日付などから[2,3]に必要なすべてのフィールドを含まなければなりません。
IFax devices MUST be compliant with MIME [4], except as noted in Appendix A.
IFAXデバイスは付録Aに述べたように除き、MIME [4]に準拠している必要があり
The data format of the facsimile image is based on the minimum set of TIFF for Facsimile [5], also known as the S profile. Such facsimile data are included in a MIME object by use of the image/TIFF sub-type [12]. Additional rules for the use of TIFF for Facsimile, for the message-based Internet facsimile application, are defined later.
ファクシミリ画像のデータ形式は、Sプロファイルとして知られているファクシミリ用TIFFの最小セット[5]に基づいています。そのようなファクシミリデータを画像/ TIFFサブタイプ[12]を用いてMIMEオブジェクトに含まれています。ファクシミリのためのTIFFの使用のための追加ルールは、メッセージベースのインターネットファクシミリアプリケーションのために、後に定義されています。
A single multi-page document SHOULD be sent as a single multi- page TIFF file, even though recipients MUST process multipart/mixed containing multiple TIFF files. If multipart content is present and processing of any part fails, then processing for the entire message is treated as failing, per [Processing failure] below.
単一のマルチページの文書は、受信者が複数のTIFFファイルを含む混合/マルチパート処理しなければならないにも関わらず、単一のマルチページTIFFファイルとして送ってください。マルチパートコンテンツが存在し、一部の処理が失敗した場合、メッセージ全体のための処理について、[処理の失敗]あたり、失敗として処理されます。
This section describes existing requirements for Internet mail, rather than indicating special requirements for IFax devices.
このセクションでは、むしろIFAXデバイスのための特別な要件を示すよりも、インターネットメールのための既存の要件について説明します。
In the event of relay failure, the sending relay MUST generate a failure message, which SHOULD be in the format of a DSN [9].
リレーが故障した場合に、送信リレーはDSN [9]の形式でなければならない失敗メッセージを生成しなければなりません。
NOTE: Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices. (See section 5.2.6.)
注：SMTPを介して輸送インターネットメールは、復帰通知を送達するためのアドレス適切からのメールを含まなければなりません。 （セクション5.2.6を参照してください。）
IFax devices with limited capabilities might be unable to process the content of a message. If this occurs it is important to ensure that the message is not lost without any notice. Notice MAY be provided in any appropriate fashion, and the exact handling is a local matter. (See Appendix A, second bullet.)
限られた機能を備えたIFAXデバイスは、メッセージの内容を処理できないことがあります。この問題が発生した場合には、メッセージが予告なしに失われていないことを確認することが重要です。通知は、任意の適切な方法で提供することができる、と正確なハンドリングは、ローカルの問題です。 （付録A、第二の箇条書きを参照してください。）
Messages being sent to normal Internet mail recipients will use standard Internet mail addresses, without additional constraints.
メッセージは、追加の制約なしに、標準のインターネットメールアドレスを使用する通常のインターネットメール受信者に送信されます。
G3Fax devices are accessed via an IFAX offramp gateway, which performs any authorized telephone dial-up.
G3FAX装置は、任意の承認電話ダイヤルアップを行うIFAXのオフランプゲートウェイを介してアクセスされます。
When a G3Fax device is identified by a telephone number, the entire address used for the G3fax device, including the number and offramp host reference MUST be contained within standard Internet mail transport fields, such as RCPT TO and MAIL FROM [1, 3]. The address MAY be contained within message content fields, such as <authentic> and <destination> [2, 3], as appropriate.
G3FAX装置は電話番号によって識別されると、数およびオフランプホスト参照含むG3FAX装置に使用される全体のアドレスは、そのようなRCPT TO及び[1,3] FROMメールなどの標準的なインターネット・メール・トランスポート・フィールド内に含まれなければなりません。アドレスは、<本物>と<宛先> [2、3]、適切なように、メッセージコンテンツフィールド内に含まれてもよいです。
As for all Internet mail addresses, the left-hand-side (local-part) of an address is not to be interpreted except by the MTA that is named on the right-hand-side (domain).
すべてのインターネットメールアドレスについては、アドレスの左手側（ローカル部分）は、右手側（ドメイン）で命名されるMTAによる場合を除いて解釈されるべきではありません。
The telephone number format SHOULD conform to [7, 8]. Other formats MUST be syntactically distinct from [7, 8].
電話番号の形式は[7,8]に準拠すべきです。他の形式は、[7]、[8]から構文的に異なるものでなければなりません。
Sending IFax devices MUST be able to write minimum set TIFF files, per the rules for creating minimum set TIFF files defined in TIFF for Facsimile (the S profile) [5], which is also compatible with the specification for the minimum subset of TIFF-F in [14]. Receiving IFax devices MUST be able to read minimum set TIFF files.
IFAXデバイスを送信するファクシミリ（Sプロファイル）のためにTIFFで定義された最小セットのTIFFファイルを作成するための規則当たり、最小セットのTIFFファイルを書き込むことができなければならない[5]、またTIFF-の最小サブセットの仕様と互換性がありますF [14]です。 IFAXデバイスを受信すると、最小セットのTIFFファイルを読み取ることができる必要があります。
A sender SHOULD NOT use TIFF fields and values beyond the minimum subset of TIFF for Facsimile unless the sender has prior knowledge of other TIFF fields or values supported by the recipient. The mechanism for determining capabilities of recipients is beyond the scope of this document.
送信者が受信者によってサポートされている他のTIFFのフィールドや値の予備知識を持っていない限り、送信者はファクシミリのためのTIFFの最小サブセットを超えてTIFFフィールドと値を使用しないでください。受信者の能力を決定するためのメカニズムはこのドキュメントの範囲を超えています。
This specification is based on use of existing Internet mail. To maintain interoperability with Internet mail, any security to be provided should be part of the of the Internet security infrastructure, rather than a new mechanism or some other mechanism outside of the Internet infrastructure.
この仕様は、既存のインターネットメールの使用に基づいています。インターネットメールとの相互運用性を維持するために、提供されるすべてのセキュリティは、インターネットセキュリティインフラストラクチャではなく、新しい機構やインターネットインフラストラクチャの外側に他のいくつかのメカニズムのの一部でなければなりません。
Both Internet mail and G3Fax standards and operational services have their own set of threats and countermeasures. This section attends only to the set of additional threats which ensue from integrating the two services. This section reviews relevant concerns about Internet mail for IFax environments, as well as considering the potential problems which can result of integrating the existing G3Fax service with Internet mail.
両方のインターネットメールとG3FAX基準や運用サービスは、脅威と対策の独自のセットを持っています。このセクションでは、唯一の2つのサービスを統合することから、結果として起きる追加脅威のセットに参加しています。このセクションでは、インターネットIFAX環境のためのメールと同様に、インターネットメールと既存G3FAXサービスを統合した結果得る潜在的な問題を考慮についての関連懸念をレビュー。
The actual sender of the message might not be the same as that specified in the Sender or From fields of the message content headers or the MAIL FROM address from the SMTP envelope.
メッセージの実際の送信者は送信者やメッセージのコンテンツヘッダやSMTPエンベロープからMAIL FROMアドレスのフィールドから、指定されたものと同じではないかもしれません。
In a tightly constrained environment, sufficient physical and software controls may be able to ensure prevention of this problem. The usual solution is through encryption-based authentication, either for the channel or associated with the object, as discussed below.
しっかりと制限された環境では、十分な物理的およびソフトウェアのコントロールは、この問題の防止を確実にすることができるかもしれません。通常の解決策は、チャンネルまたは後述するように、オブジェクトに関連付けられているいずれか、暗号化ベースの認証を介してです。
It should be recognized that SMTP implementations do not provide inherent authentication of the senders of messages, nor are sites under obligation to provide such authentication. End-to-end approaches such as S/MIME and PGP/MIME are currently being developed within the IETF. These technologies can provide such authentication.
SMTPの実装は、メッセージの送信者の固有の認証を提供せず、また、このような認証を提供する義務の下にサイトがあることを認識すべきです。このようなS / MIMEおよびPGP / MIMEなどのエンドツーエンドのアプローチは、現在、IETF内で開発されています。これらの技術は、このような認証を提供することができます。
In addition to the resources normally consumed for email (CPU cycles and disk), offramp facsimile causes an outdial which often imposes significant resource consumption, such as financial cost. Techniques for establishing authorization of the sender are essential to those offramp facsimile services that need to manage such consumption.
通常、電子メール（CPUサイクルとディスク）のために消費されるリソースに加えて、オフランプファクシミリは、多くの場合、金融費用として、重要なリソース消費を課しアウトダイヤルが発生します。送信者の認証を確立するための技術は、このような消費を管理するために必要なものをオフランプファクシミリサービスに不可欠です。
Due to the consumption of these resources by dialout, unsolicited bulk email which causes an outdial is undesirable.
ダイヤルアウトすることにより、これらのリソースの消費に、アウトダイヤルが発生し、迷惑メールは望ましくありません。
Offramp gateways SHOULD provide the ability to authorize senders in some manner to prevent unauthorized use of the offramp. There are no standard techniques for authorization using Internet protocols.
オフランプゲートウェイは、オフランプの不正使用を防止するために、いくつかの方法で、送信者を認証する機能を提供すべきです。インターネット・プロトコルを使用して、認可のための標準的な技術はありません。
Typical solutions use simple authentication of the originator to establish and verify their identity and then check the identity against a private authorization table.
典型的なソリューションは、確立し、彼らの身元を確認してから民間の認可テーブルに対して身元を確認するために発信者の簡易認証を使用しています。
Originator authentication entails the use of weak or strong mechanisms, such as cleartext keywords or encryption-based data-signing, respectively, to determine and validate the identify of the sender and assess permissions accordingly.
発信元認証は、送信者の識別し、それに応じてアクセス権を評価を決定し、検証するために、それぞれ、このような平文キーワードまたは暗号化ベースのデータ署名などの弱いまたは強い機構の使用を伴います。
Other control mechanisms which are common include source filtering and originator authentication. Source filtering entails offramp gateway verification of the host or network originating the message and permitting or prohibiting relaying accordingly.
共通する他の制御メカニズムは、ソースフィルタリングと発信元認証を含みます。ソースフィルタは、ホストまたはネットワークメッセージを発信し、許可または禁止に応じて中継のオフランプゲートウェイ検証を伴います。
Confidential information about the sender necessary to dial a G3Fax recipient, such as sender's calling card authorization number, might be disclosed to the G3Fax recipient (on the cover page), such as through parameters encoded in the G3Fax recipients address in the To: or CC: fields.
またはCC：そのような送信者のコーリングカードの承認番号などG3FAXの受信者をダイヤルするために必要な送信者に関する機密情報は、受信者がに対処G3FAXで符号化されたパラメータを介するよう、（表紙の）G3FAX受信者に開示されるかもしれません：フィールド。
Senders SHOULD be provided with a method of preventing such disclosure. As with mechanisms for handling unsolicited faxes, there are not yet standard mechanisms for protecting such information.
送信者は、そのような開示を防止する方法が提供されるべきです。迷惑ファックスを処理するためのメカニズムと同様に、そのような情報を保護するための標準的なメカニズムはまだ存在しません。
Out-of-band communication of authorization information or use of encrypted data in special fields are the available non-standard techniques.
特殊な分野での暗号化されたデータの認証情報や使用のアウト・オブ・バンド通信が可能な非標準的な技術です。
Typically authorization needs to be associated to specific senders and specific messages, in order to prevent a "replay" attack which causes and earlier authorization to enable a later dial-out by a different (and unauthorized) sender. A non-malicious example of such a replay would be to have an email recipient reply to all original recipients -- including an offramp IFax recipient -- and have the original sender's authorization cause the reply to be sent.
通常、認可が原因となり、異なる（不正）送信者が、後にダイヤルアウトを有効にするには、以前の承認「リプレイ」攻撃を防ぐために、特定の送信者や特定のメッセージに関連付けられてする必要があります。オフランプIFAXの受信者を含む - - そのようなリプレイの非悪意の例では、すべての元の受信者に電子メールの受信者の返信を持っているだろうし、元の送信者の権限を持っている回答が送られます。
In many countries, there is a legal requirement that the "sender" be disclosed on a facsimile message. Email From addresses are trivial to fake, so that using only the MAIL FROM [1, 3] or From [2, 3] header is not sufficient.
多くの国では、「送信者は」ファクシミリメッセージに開示されることの法的要件があります。又はから[2、3]ヘッダは不十分である[3,1]のみからメールを使用するようにアドレスからの電子メールは、偽に自明です。
Offramps SHOULD ensure that the recipient is provided contact information about the offramp, in the event of problems.
オフランプは、受信者が問題が発生した場合には、オフランプについての連絡先情報を提供していることを確認する必要があります。
The G3Fax recipient SHOULD be provided with sufficient information which permits tracing the originator of the IFax message. Such information might include the contents of the MAIL FROM, From, Sender and Reply-To headers, as well as Message-Id and Received headers.
G3FAX受信者は、IFAXのメッセージの発信元を追跡可能にする十分な情報を提供されるべきです。このような情報は送信者から、、、MAIL FROMの内容を含めると返信先のヘッダーだけでなく、メッセージIDとReceivedヘッダーかもしれません。
Users of G3Fax devices have an expectation of a level of message privacy which is higher than the level provided by Internet mail without security enhancements.
G3FAXデバイスのユーザーは、セキュリティの強化せずにインターネットメールが提供するレベルより高いメッセージプライバシーのレベルの期待を持っています。
This expectation of privacy by G3Fax users SHOULD be preserved as much as possible.
G3FAXのユーザーによるプライバシーのこの予想は、可能な限り保存されるべきです。
Sufficient physical and software control may be acceptable in constrained environments. The usual mechanism for ensuring data confidentially entail encryption, as discussed below.
十分な物理的およびソフトウェアの制御は制限された環境において許容可能です。以下に述べるように、データが秘密裏に、暗号化を伴う確保するための通常のメカニズム。
With email, bounces (delivery failures) are typically returned to the sender and not to a publicly-accessible email account or printer. With facsimile, bounces do not typically occur. However, with IFax, a bounce could be sent elsewhere (see section [Delivery Failure]), such as a local system administrator's account, publicly-accessible account, or an IFax printer (see also [Traffic Analysis]).
電子メールでは、バウンス（配信の失敗）は、通常、公的にアクセス可能なメールアカウントやプリンタに送信者に返送していません。ファクシミリでは、バウンスは、一般的に発生しません。しかし、IFAXで、バウンスは、ローカルシステム管理者アカウントとして、公的にアクセス可能なアカウント、またはIFAXプリンタ（[トラフィック分析]も参照）（セクション[配信の失敗]を参照）別の場所に送ることができます。
Eavesdropping of senders and recipients is easier on the Internet than GSTN. Note that message object encryption does not prevent traffic analysis, but channel security can help to frustrate attempts at traffic analysis.
送信者と受信者の盗聴はGSTNよりも、インターネット上に簡単です。そのメッセージオブジェクトの暗号化は、トラフィック解析を防ぐことはできませんが、チャネルのセキュリティは、トラフィック分析の試みを挫折するのに役立つことができます。
There are two basic approaches to encryption-based security which support authentication and privacy:
認証とプライバシーをサポートする暗号化ベースのセキュリティへの2つの基本的なアプローチがあります。
As with all email, an IFax message can be viewed as it traverses internal networks or the Internet itself.
それは内部ネットワークまたはインターネット自体を通過するときにすべての電子メールと同じように、IFAXのメッセージを表示することができます。
Virtual Private Networks (VPN), encrypted tunnels, or transport layer security can be used to prevent eavesdropping of a message as it traverses such networks. It also provides some protection against traffic analysis, as described above.
それはこのようなネットワークを横断するときに仮想プライベートネットワーク（VPN）、暗号化トンネル、またはトランスポート層セキュリティは、メッセージの盗聴を防止するために用いることができます。上記のようにそれはまた、トラフィック解析に対するいくつかの保護を提供します。
At the current time various protocols exist for performing the above functions, and are only mentioned here for information. Such protocols are IPSec [17] and TLS [18].
現時点で様々なプロトコルは、上記の機能を実行するために存在し、情報のみのためにここに記載されています。そのようなプロトコルは、IPSec [17]、およびTLS [18]です。
As with all email, an IFax message can be viewed while it resides on, or while it is relayed through, an intermediate Mail Transfer Agent.
それが常駐しながら、すべての電子メールと同じように、IFAXのメッセージを表示することができ、またはそれは中間のメール転送エージェントを通じて中継されながら。
Message encryption can be used to provide end-to-end encryption.
メッセージの暗号化は、エンドツーエンドの暗号化を提供するために使用することができます。
At the current time two protocols are commonly used for message encryption and are only mentioned here for information. The two protocols are PGP-MIME [16] and S/MIME [19].
現在の時点では2つのプロトコルは、一般的にメッセージの暗号化に使用され、情報だけのためにここに記載されています。 2つのプロトコルであるPGP-MIME [16]及びS / MIME [19]。
[1] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[1] Klensin、J.、エディタ、 "簡易メール転送プロトコル"、RFC 2821、2001年4月。
[2] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.
[2]レズニック、P.、エディタ、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[3]ブレーデン、R.、 "インターネットホストのための要件 - アプリケーションとサポート"、STD 3、RFC 1123、1989年10月。
[4] Borenstein, N. and N. Freed, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[4] Borenstein、N.とN.フリード、 "多目的インターネットメール拡張（MIME）パート5：適合基準と例"、RFC 2049、1996年11月。
[5] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, November 2004.
[5]バックリー、R.、VENABLE、D.、マッキンタイア、L.、パーソンズ、G.、およびJ.・ラファティ、 "インターネットファクスのファイル形式"、RFC 3949、2004年11月。
[6] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[6]マイヤーズ、J.とM.ローズ、 "ポストオフィスプロトコル - バージョン3"、STD 53、RFC 1939、1996年5月を。
[7] Allocchio, C., "Minimal GSTN address format for Internet mail", RFC 3191, October 2001.
[7] Allocchio、C.、 "インターネットメールのための最小限のGSTNアドレス形式"、RFC 3191、2001年10月に。
[8] Allocchio, C., "Minimal fax address format for Internet mail", RFC 3192, October 2001.
[8] Allocchio、C.、 "インターネットメールのための最小限のファックスアドレス形式"、RFC 3192、2001年10月に。
[9] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[9]ムーア、K.、およびG.ボードルイ、 "配送状態通知のための広げることができるメッセージフォーマット"、RFC 3464、2003年1月。
[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[10]解放され、N.とN. Borenstein、 "マルチパーパスインターネットメールエクステンション（MIME）パート2：メディアタイプ"、RFC 2046、1996年11月。
[11] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[11]ムーア、K. "MIME（多目的インターネットメール拡張）パート3：非ASCIIテキストのためのメッセージヘッダの拡張"、RFC 2047、1996年11月。
[12] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration", RFC 3302, September 2002.
[12]パーソンズ、G.とJ.・ラファティ、 "タグイメージファイル形式（TIFF） - 画像/ TIFFのMIMEサブタイプ登録"、RFC 3302、2002年9月。
[13] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[13]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[14] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998.
[14]パーソンズ、G.とJ.・ラファティ、 "タグイメージファイル形式（TIFF） - ファクシミリのためのFプロフィール"、RFC 2306、1998年3月。
[15] ITU-T (CCITT), "Standardization of Group 3 facsimile apparatus for document transmission", ITU-T (CCITT), Recommendation T.4.
[15] ITU-T（CCITT）、 "文書伝送用グループ3ファクシミリ装置の標準化"、ITU-T（CCITT）、勧告T. 4。
[16] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[16]カラス、J.、Donnerhacke、L.、フィニー、H.、およびR.セイヤー、 "OpenPGPのメッセージフォーマット"、RFC 2440、1998年11月。
[17] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[17]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[18] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[18]ホフマン、P.、 "トランスポート層セキュリティの安全なSMTPのためのSMTPサービス拡張子"、RFC 3207、2002年2月。
[19] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[19] Ramsdell、B.、 "S / MIMEバージョン3メッセージ仕様"、RFC 2633、1999年6月。
This specification was produced by the Internet Engineering Task Force Fax Working Group, over the course of more than one year's online and face-to-face discussions. As with all IETF efforts, many people contributed to the final product.
この仕様は、一年以上のオンラインと対面議論の過程で、インターネットエンジニアリングタスクフォースファックスワーキンググループによって作成されました。すべてのIETFの努力と同じように、多くの人々が、最終製品に貢献しました。
Active for this document were: Steve Huston, Jeffrey Perry, Greg Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne, Robert A. Rosenberg, Larry Masinter, Dave Crocker, Herman Silbiger, James Rafferty.
このドキュメントのためにアクティブだった：スティーブ・ヒューストン、ジェフリー・ペリー、グレッグボードルイ、リチャードショッキー、チャールズ・ウー、グラハムKlyne、ロバート・A・ローゼンバーグ、ラリーMasinter、デイブ・クロッカー、ハーマンSilbiger、ジェームズ・ラファティ。
Appendix A: Exceptions to MIME
付録A：MIMEの例外
* IFax senders are not required to be able to send text/plain messages (RFC 2049 requirement 4), although IFax recipients are required to accept such messages, and to process them.
IFAX受信者がそのようなメッセージを受け入れるために、それらを処理するために必要とされるものの* IFAX送信者は、text / plainのメッセージ（RFC 2049の要件4）を送信することができるように要求されません。
* IFax recipients are not required to offer to put results in a file. (Also see 2.3.2.)
* IFAX受信者がファイルに結果を置くために提供する必要はありません。 （また、2.3.2を参照してください。）
* IFax recipients MAY directly print/fax the received message rather than "display" it, as indicated in RFC 2049.
* IFAXの受信者は、直接ではなく、RFC 2049に示されるように、「表示」、それより受信したメッセージをファックス/印刷することができます。
Appendix B: List of edits to RFC 2305
付録B：RFC 2305に編集一覧
+----+----------+-------------------------------------------------+
| No.| Section | Edit July 27, 2001 |
+----+----------+-------------------------------------------------+
| 1. |Copyright | Updated copyright from "1998" to "1999,2000" |
| |Notice | |
+----+----------+-------------------------------------------------+
| 2. |SUMMARY | Changed the phrase "over the Internet" to |
| | | "using Internet mail" |
+----+----------+-------------------------------------------------+
| 3. |5 | Changed the paragraphs regarding to the |
| | | following references to make them very |
| | | non-normative. |
| | | "OpenPGP Message Format", RFC 2440 |
| | | "Security Architecture for the IP", RFC 2401 |
| | | "SMTP Service Extensions for Secure SMTP over |
| | | TLS", RFC 2487 |
| | | "S/MIME Version 2 Message Specification", |
| | | RFC 2311 |
+----+----------+-------------------------------------------------+
| 4. |REFERENCES| Removed the following references because they |
| | | are non-normative |
| | | "SMTP Service Extensions for Delivery Status |
| | | Notifications", RFC 1891 |
| | | "Internet Message Access Protocol", RFC 2060 |
+----+----------+-------------------------------------------------+
| 5. |REFERENCES| Separated REFERENCES to the normative and |
| | | non-normative |
+----+----------+-------------------------------------------------+
| 6. |Appendix | Changed the phrase from "NOT REQUIRED" to |
| | A | "not required" |
+----+----------+-------------------------------------------------+
| 7. |Appendix | Added "Appendix B List of edits to RFC 2305" |
+----+----------+-------------------------------------------------+
Authors' Addresses
著者のアドレス
Kiyoshi Toyoda Panasonic Communications Co., Ltd. 4-1-62 Minoshima Hakata-ku Fukuoka 812-8531 Japan
きよし とよだ ぱなそにｃ こっむにかちおんｓ こ。、 Ｌｔｄ。 ４ー１ー６２ みのしま はかたーく ふくおか ８１２ー８５３１ じゃぱん
Fax: +81 92 477 1389 EMail: toyoda.kiyoshi@jp.panasonic.com
ファックス：+81 92 477 1389 Eメール：toyoda.kiyoshi@jp.panasonic.com
Hiroyuki Ohno National Institute of Information and Communications Technology 4-2-1, Nukui-Kitamachi, Koganei, Tokyo, 184-8795, Japan
ひろゆき おｈの なちおなｌ いんｓちつて おｆ いんふぉｒまちおん あんｄ こっむにかちおんｓ てｃｈのぉｇｙ ４ー２ー１、 ぬくいーきたまち、 こがねい、 ときょ、 １８４ー８７９５、 じゃぱん
Fax: +81 42 327 7941 EMail: hohno@ohnolab.org
ファックス：+81 42 327 7941 Eメール：hohno@ohnolab.org
Jun Murai Keio University 5322 Endo, Fujisawa Kanagawa 252 Japan
じゅん むらい けいお うにゔぇｒしｔｙ ５３２２ えんど、 ふじさわ かながわ ２５２ じゃぱん
Fax: +81 466 49 1101 EMail: jun@wide.ad.jp
ファックス：+81 466 49 1101 Eメール：jun@wide.ad.jp
Dan Wing 170 W. Tasman Drive San Jose, CA 95134 USA
ダン・ウィング170 W.タスマン・ドライブサンノゼ、CA 95134 USA
Phone: +1 408 525 5314 EMail: dwing@cisco.com
電話：+1 408 525 5314 Eメール：dwing@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。