[要約] RFC 2305は、インターネットメールを使用した簡単なファクシミリモードに関する規格です。このRFCの目的は、インターネットメールを介してファクシミリを送受信するためのシンプルな方法を提供することです。
Network Working Group K. Toyoda
Request for Comments: 2305 H. Ohno
Category: Standards Track J. Murai
WIDE Project
D. Wing
Cisco
March 1998
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 (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
SUMMARY
概要
This specification provides for "simple mode" carriage of facsimile data over the Internet. Extensions to this document will follow. The current specification employs standard protocols and file formats such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 16, 17], and TIFF for Facsimile [5,6,19]. 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、インターネットメールプロトコル[1、2、3]、MIME [4、16、17]、ファクシミリ用のTIFF [5、6、19]などの標準プロトコルとファイル形式を採用しています。他のインターネット対応ファクシミリデバイスだけでなく、MIMEメールやファクシミリデータのTIFFを処理できる一般的な電子メールリーダーを備えたPCなどのインターネットネイティブシステムにも画像を送信できます。この仕様は、既存のファクシミリデバイス、インターネットメールエージェント、およびそれらを接続するゲートウェイ間の通信を容易にします。
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [7].
このドキュメントのキーワード「MUST」、「SHOULD」、「SHOULD NOT」、および「MAY」は、[7]で説明されているように解釈されます。
1 SCOPE
1スコープ
This specification defines a 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 [8] 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 [8]と一般交換電話網（GSTN）を使用するファクシミリ対応デバイスは、この仕様では「G3Faxデバイス」と呼ばれます。 「IFaxデバイス」とは、インターネットFAXを送信、受信、または転送できるインターネットアクセス可能なデバイスです。メッセージは、インターネットメールアドレスを使用してIFaxデバイスに送信できます。メッセージは、インターネットメールアドレスを使用してG3Faxデバイスに送信できます。メッセージはIFax offrampゲートウェイを介して転送される場合があります。
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
2 COMMUNICATION PROTOCOLS
2通信プロトコル
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-spec>およびRFC 822 <mailbox>インターネットメール標準[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).
ゲートウェイは、異なる環境間で変換を行います。 IFaxの場合、ゲートウェイはインターネットメールとT.4 / GSTNファクシミリの間を接続します。ゲートウェイは、複数のT.4 / GSTNファクシミリユーザーにサービスを提供することも、1人だけにサービスを提供することもできます。前者の場合、これらは従来の「メール転送エージェント」（MTA）として機能し、後者の場合、従来の「メールユーザーエージェント」（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.
オンランプは、T.4 / GSTNファクシミリからインターネットメールに接続するゲートウェイです。 offrampは、インターネットメールから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.
この仕様は、ofmpのアドレス指定、確認、および障害通知のインターネットメールサービス部分について説明しています。詳細は後のセクションで説明します。
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 or IMAP [9, 10].
複数のユーザーにサービスを提供するMTAとして動作するofframpゲートウェイは、SMTPを使用する必要があります。単一のメール受信者にサービスを提供するUAとして動作するゲートウェイは、POPやIMAPなどのメールボックスアクセスプロトコルを使用できます[9、10]。
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 822 and RFC1123, 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 822およびRFC1123に準拠する必要があります。 IFaxメッセージのヘッダーにはMessage-IDを含める必要があり（SHOULD）、DATEやFROMなど、[2、3]で必要なすべてのフィールドを含める必要があります。
IFax devices MUST be compliant with MIME [4], except as noted in Appendix A.
付録Aに記載されている場合を除き、IFaxデバイスはMIME [4]に準拠している必要があります。
The data format of the facsimile image is based on the minimum set of TIFF for Facsimile[6], also known as the S profile. Such facsimile data are included in a MIME object by use of the image/TIFF sub-type [19]. Additional rules for the use of TIFF for Facsimile, for the message-based Internet facsimile application, are defined later.
ファクシミリ画像のデータ形式は、Sプロファイルとしても知られている、ファクシミリ[6]のTIFFの最小セットに基づいています。このようなファクシミリデータは、image / TIFFサブタイプを使用してMIMEオブジェクトに含まれます[19]。メッセージベースのインターネットファクシミリアプリケーション用のTIFF for Facsimileの使用に関する追加のルールは、後で定義されます。
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ファイルを含むmultipart / mixedを処理する必要がある場合でも、単一のマルチページドキュメントは単一のマルチページTIFFファイルとして送信する必要があります（SHOULD）。マルチパートコンテンツが存在し、いずれかの部分の処理が失敗した場合、メッセージ全体の処理は、以下の[処理の失敗]に従って失敗として処理されます。
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. [14,15]
リレーに障害が発生した場合、送信側のリレーは障害メッセージを生成する必要があります。このメッセージはDSNの形式である必要があります（SHOULD）。 [14、15]
NOTE: Internet mail transported via SMTP MUST contain a MAIL FROM address appropriate for delivery of return notices [Also see section 5.2.6]
注：SMTP経由で転送されるインターネットメールには、返信通知の配信に適したMAIL FROMアドレスが含まれている必要があります[セクション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. (Also see Appendix A, second bullet.)
機能が制限されているIFaxデバイスは、メッセージのコンテンツを処理できない場合があります。これが発生した場合、通知なしにメッセージが失われないようにすることが重要です。通知は適切な方法で提供される場合があり、正確な処理は地域の問題です。 （また、付録Aの2番目の項目を参照してください。）
3 ADDRESSING
3アドレッシング
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 offrampゲートウェイを介してアクセスします。ゲートウェイは、許可された電話のダイヤルアップを実行します。
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やMAIL FROM [1、3]などの標準インターネットメールトランスポートフィールドに含まれている必要があります。アドレスは、<authentic>や<destination> [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 [11, 12]. Other formats MUST be syntactically distinct from [11, 12].
電話番号の形式は[11、12]に準拠する必要があります（SHOULD）。他のフォーマットは、[11、12]とは構文的に異なる必要があります。
4 IMAGE FILE FORMAT
4画像ファイル形式
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) [6], which is also compatible with the specification for the minimum subset of TIFF-F in [5]. Receiving IFax devices MUST be able to read minimum set TIFF files.
送信IFaxデバイスは、ファクシミリ（Sプロファイル）のTIFFで定義された最小セットTIFFファイルを作成するためのルールに従って、最小セットTIFFファイルを書き込むことができる必要があります[6]。これは、TIFFの最小サブセットの仕様とも互換性があります。 [5]のF。 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フィールドおよび値を使用してはなりません（SHOULD NOT）。受信者の機能を判別するメカニズムは、このドキュメントの範囲外です。
5 SECURITY CONSIDERATIONS
5セキュリティに関する考慮事項
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.
メッセージの実際の送信者は、メッセージコンテンツヘッダーのSenderまたはFromフィールド、または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.
オフランプゲートウェイは、何らかの方法で送信者を承認して、オフランプの不正使用を防止する機能を提供する必要があります（SHOULD）。インターネットプロトコルを使用した認証の標準的な手法はありません。
Typical solutions use simple authentication of the originator to establish and verify their identity and then check the identity against a private authorization table.
一般的なソリューションでは、発信者の単純な認証を使用してIDを確立および検証し、IDをプライベート認可テーブルと照合します。
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.
発信者認証では、クリアテキストキーワードや暗号化ベースのデータ署名など、弱いメカニズムや強いメカニズムを使用して、送信者のIDを特定および検証し、それに応じてアクセス許可を評価します。
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.
送信者のコーリングカード承認番号など、G3Fax受信者にダイヤルするために必要な送信者に関する機密情報は、To：またはCCの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.
送信者は、そのような開示を防ぐ方法を提供されるべきです。迷惑なFAXを処理するメカニズムと同様に、そのような情報を保護する標準的なメカニズムはまだありません。許可情報の帯域外通信または特別なフィールドでの暗号化データの使用は、非標準の技術として利用できます。
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.
多くの国では、「送信者」をファクシミリメッセージで開示するという法的要件があります。電子メールのFromアドレスは偽造するのは簡単です。そのため、MAIL FROM [1、3]またはFrom [2、3]ヘッダーのみを使用するだけでは不十分です。
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メッセージの発信者を追跡できる十分な情報を提供する必要があります（SHOULD）。そのような情報には、MAIL FROM、From、Sender、およびReply-Toヘッダーのコンテンツ、ならびにMessage-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) which make use of encrypted tunnels, such as via IPSec technology [18] 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.
IPSecテクノロジー[18]やトランスポート層セキュリティなどを介して暗号化されたトンネルを利用する仮想プライベートネットワーク（VPN）を使用すると、そのようなネットワークを通過するメッセージの盗聴を防止できます。上記のように、トラフィック分析に対する保護も提供します。
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メッセージは、中間のMail Transfer Agentに常駐しているとき、または中継されているときに表示できます。
Message encryption, such as PGP-MIME [13] and S/MIME, can be used to provide end-to-end encryption.
PGP-MIME [13]やS / MIMEなどのメッセージ暗号化を使用して、エンドツーエンドの暗号化を提供できます。
6 REFERENCES
6参考文献
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel、J。、「Simple Mail Transfer Protocol」、STD 10、RFC 821、1982年8月。
[2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August l982.
[2] Crocker、D。、「ARPAインターネットテキストメッセージのフォーマットの標準」、STD 11、RFC 822、8月l982。
[3] Braden, R., 1123 "Requirements for Internet hosts - application and support", RFC 1123, October 1989.
[3] ブレーデン、R.、1123「インターネットホストの要件-アプリケーションとサポート」、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. Freed、「Multipurpose Internet Mail Extensions（MIME）Part Five：Conformance Criteria and Examples」、RFC 2049、1996年11月。
[5] Parsons, G., and J. Rafferty, "Tag Image File Format (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998.
[5] Parsons、G。、およびJ. Rafferty、「Tag Image File Format（TIFF）-F Profile for Facsimile」、RFC 2306、1998年3月。
[6] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998.
[6] McIntyre、L.、Zilles、S.、Buckley、R.、Venable、D.、Parsons、G。、およびJ. Rafferty、「インターネットFAXのファイル形式」、RFC 2301、1998年3月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[7] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、RFC 2119、1997年3月。
[8] ITU-T (CCITT), "Standardization of Group 3 facsimile apparatus for document transmission", ITU-T (CCITT), Recommendation T.4.
[8] ITU-T（CCITT）、「文書送信のためのグループ3ファクシミリ装置の標準化」、ITU-T（CCITT）、勧告T.4。
[9] Myers, J., and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[9] マイヤーズ、J。、およびM.ローズ、「Post Office Protocol-Version 3」、STD 53、RFC 1939、1996年5月。
[10] Crispin, M., "Internet Message Access Protocol - Version 4Rev1", RFC 2060, December 1996.
[10] Crispin、M.、「インターネットメッセージアクセスプロトコル-バージョン4Rev1」、RFC 2060、1996年12月。
[11] Allocchio, C., "Minimal PSTN address format for Internet mail", RFC 2303, March 1998.
[11] Allocchio、C。、「インターネットメールの最小PSTNアドレス形式」、RFC 2303、1998年3月。
[12] Allocchio, C., "Minimal fax address format for Internet mail", RFC 2304, March 1998.
[12] Allocchio、C。、「インターネットメールの最小FAXアドレス形式」、RFC 2304、1998年3月。
[13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC 2015, October 1996.
[13] Elkins、M。、「MIME Security with Pretty Good Privacy（PGP）」、RFC 2015、1996年10月。
[14] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996.
[14] Moore、K。、およびG. Vaudreuil、「An Extensible Message Format for Delivery Status Notifications」、RFC 1894、1996年1月。
[15] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
[15] ムーアK.、「配信ステータス通知のSMTPサービス拡張」、RFC 1891、1996年1月。
[16] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[16] Freed、N。、およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、1996年11月。
[17] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Three: Representation of Non-ASCII Text in Internet ge Headers", RFC 2047, November 1996.
[17] ムーアK.、「多目的インターネットメール拡張（MIME）3：インターネットgeヘッダーでの非ASCIIテキストの表現」、RFC 2047、1996年11月。
[18] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, August 1995.
[18] Atkinson、R.、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 1825、海軍研究所、1995年8月。
[19] Parsons, G. and Rafferty, J. "Tag Image File Format (TIFF) -- image/TIFF: MIME Sub-type Registration", RFC 2302, March 1998.
[19] パーソンズ、G。およびラファティ、J。「タグイメージファイルフォーマット（TIFF）-image / TIFF：MIMEサブタイプ登録」、RFC 2302、1998年3月。
7 ACKNOWLEDGEMENTS
7謝辞
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.
この仕様は、インターネットエンジニアリングタスクフォースのFAXワーキンググループによって、1年以上のオンラインおよび対面での議論の過程で作成されました。すべての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.
このドキュメントでアクティブだったのは、Steve Huston、Jeffrey Perry、Greg Vaudreuil、Richard Shockey、Charles Wu、Graham Klyne、Robert A. Rosenberg、Larry Masinter、Dave Crocker、Herman Silbiger、James Raffertyです。
8 AUTHORS' ADDRESSES
8作者のアドレス
Kiyoshi Toyoda Matsushita Graphic Communication Systems, Inc. 2-3-8 Shimomeguro, Meguro-ku Tokyo 153 Japan Fax: +81 3 5434 7166 Email: ktoyoda@rdmg.mgcs.mei.co.jp
Kiyoshi Toyoda Matsushita Graphic Communication Systems, Inc. 2-3-8 Shimomeguro, Meguro-ku Tokyo 153 Japan Fax: +81 3 5434 7166 Email: ktoyoda@rdmg.mgcs.mei.co.jp
Hiroyuki Ohno Tokyo Institute of Technology 2-12-1 O-okayama, Meguro-ku Tokyo 152 Japan FAX: +81 3 5734 2754 Email: hohno@is.titech.ac.jp
ひろゆき おｈの ときょ いんｓちつて おｆ てｃｈのぉｇｙ ２ー１２ー１ おーおかやま、 めぐろーく ときょ １５２ じゃぱん ふぁＸ： ＋８１ ３ ５７３４ ２７５４ えまいｌ： ほｈの＠いｓ。ちてｃｈ。あｃ。ｊｐ
Jun Murai Keio University 5322 Endo, Fujisawa Kanagawa 252 Japan Fax: +81 466 49 1101 Email: jun@wide.ad.jp
じゅん むらい けいお うにゔぇｒしｔｙ ５３２２ えんど、 ふじさわ かながわ ２５２ じゃぱん ふぁｘ： ＋８１ ４６６ ４９ １１０１ えまいｌ： じゅん＠うぃで。あｄ。ｊｐ
Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 USA Phone: +1 408 457 5200 Fax: +1 408 457 5208 Email: dwing@cisco.com
Dan Wing Cisco Systems、Inc. 101 Cooper Street Santa Cruz、CA 95060 USA電話：+1408457 5200ファックス：+1408457 5208メール：dwing@cisco.com
9 APPENDIX A: Exceptions to MIME
9付録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送信者は、テキスト/プレーンメッセージ（RFC 2049要件4）を送信できる必要はありませんが、IFax受信者はそのようなメッセージを受け入れて処理する必要があります。
* 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に示されているように、受信したメッセージを「表示」するのではなく、直接印刷またはFAXで送信する場合があります。
10 Full Copyright Statement
10完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されない一切の保証を含みません。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。