[要約] RFC 3965は、インターネットメールを使用した簡単なファクシミリモードに関する規格です。このRFCの目的は、電子メールを介してファクシミリを送受信するための標準的な方法を提供することです。
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 オフランプ ゲートウェイ経由で転送されてもよい (MAY)。
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
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].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。[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-spec> および RFC 822 <mailbox> インターネット メール標準 [1、2、3] に準拠しなければなりません (MUST)。
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 ファクシミリ ユーザーにサービスを提供することも、1 人のユーザーのみにサービスを提供することもできます。前者の場合は従来の「メール転送エージェント」(MTA) として機能し、後者の場合は従来の「メール ユーザー エージェント」(UA) として機能します。オンランプは、T.4/GSTN ファクシミリからインターネット メールに接続するゲートウェイです。オフランプは、インターネットメールから T.4/GSTN ファクシミリに接続するゲートウェイです。オンランプの動作はこの仕様の範囲外です。
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 を使用すべきです (SHOULD)。単一のメール受信者にサービスを提供する UA として動作するゲートウェイは、POP [6] または同様のメールボックス アクセス プロトコルなどのメールボックス アクセス プロトコルを使用してもよい(MAY)。
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 メッセージのヘッダーには、Message-ID が含まれる必要があり (SHOULD)、DATE や FROM など、[2, 3] で要求されるすべてのフィールドが含まれなければなりません (MUST)。
IFax devices MUST be compliant with MIME [4], except as noted in Appendix A.
IFax デバイスは、付録 A に記載されている場合を除き、MIME [4] に準拠しなければなりません (MUST)。
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] に基づいています。このようなファクシミリ データは、image/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 ファイルとして送信されるべきです(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 [9].
リレー障害が発生した場合、送信側リレーは障害メッセージを生成しなければなりません (MUST)。これは 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 経由で転送されるインターネット メールには、返送通知の配信に適した 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. (See Appendix A, second bullet.)
機能が制限されている IFax デバイスでは、メッセージのコンテンツを処理できない場合があります。この問題が発生した場合は、通知なしにメッセージが失われないようにすることが重要です。通知は適切な方法で提供されてもよく、正確な取り扱いは地域の問題です。(付録 A の 2 番目の箇条書きを参照してください。)
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 や MAIL FROM [1、3] などの標準インターネット メール トランスポート フィールド内に含まれなければなりません (MUST)。アドレスは、必要に応じて、<authentic> や <destination> [2, 3] などのメッセージ コンテンツ フィールド内に含めてもよい[MAY]。
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] に準拠する必要があります (SHOULD)。他の形式は構文的に [7, 8] とは異なっていなければなりません (MUST)。
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 デバイスは、ファクシミリ用 TIFF (S プロファイル) [5] で定義された最小セット TIFF ファイルの作成規則に従って、最小セット TIFF ファイルを書き込むことができなければなりません (MUST)。これは、TIFF の最小サブセットの仕様とも互換性があります。[14]の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)。受信者の能力を決定するメカニズムについては、このドキュメントの範囲を超えています。
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.
オフランプ ゲートウェイは、オフランプの不正使用を防ぐために、何らかの方法で送信者を承認する機能を提供すべきです (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.
発信者認証では、送信者の身元を特定および検証し、それに応じてアクセス許可を評価するために、それぞれ平文キーワードや暗号化ベースのデータ署名などの弱いメカニズムまたは強力なメカニズムの使用が必要になります。
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.
認証情報の帯域外通信や特殊なフィールドでの暗号化データの使用は、利用可能な非標準技術です。
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.
多くの国では、ファクシミリ メッセージで「送信者」を開示することが法的に義務付けられています。電子メールの差出人アドレスは簡単に偽装されるため、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.
オフランプは、問題が発生した場合に、受信者にオフランプに関する連絡先情報が提供されることを保証すべきです(SHOULD)。
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), 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.、編集者、「Simple Mail Transfer Protocol」、RFC 2821、2001 年 4 月。
[2] Resnick, P., Editor, "Internet Message Format", RFC 2822, April 2001.
[2] Resnick, P.、編集者、「インターネット メッセージ フォーマット」、RFC 2822、2001 年 4 月。
[3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[3] Braden, 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. Freed、「MultiPurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples」、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] Buckley, R.、Venable, D.、McIntyre, L.、Parsons, G.、および J. Rafferty、「インターネット FAX のファイル形式」、RFC 3949、2004 年 11 月。
[6] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[6] Myers、J. および M. Rose、「Post Office Protocol - Version 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.、「インターネット メールの最小 FAX アドレス形式」、RFC 3192、2001 年 10 月。
[9] Moore, K., and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[9] Moore, K.、および G. Vaudreuil、「配信ステータス通知のための拡張可能なメッセージ形式」、RFC 3464、2003 年 1 月。
[10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[10] Freed, 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] Moore, 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] Parsons, G. および J. Rafferty、「タグ イメージ ファイル フォーマット (TIFF) - image/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] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、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] Parsons, G. および J. Rafferty、「タグ イメージ ファイル フォーマット (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] Callas, J.、Donnerhacke, L.、Finney, H.、R. Thayer、「OpenPGP Message Format」、RFC 2440、1998 年 11 月。
[17] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[17] Kent, S. および R. Atkinson、「インターネット プロトコルのセキュリティ アーキテクチャ」、RFC 2401、1998 年 11 月。
[18] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002.
[18] Hoffman, 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.
この仕様は、インターネット エンジニアリング タスク フォースのファックス ワーキング グループによって、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.
この文書の執筆に携わったのは、スティーブ ヒューストン、ジェフリー ペリー、グレッグ ヴォードルイユ、リチャード ショッキー、チャールズ ウー、グラハム クライン、ロバート A. ローゼンバーグ、ラリー マシンター、デイブ クロッカー、ハーマン シルビガー、ジェームズ ラファティです。
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 送信者はテキスト/プレーン メッセージ (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 してもよい(MAY)。
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
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
Hiroyuki Ohno National Institute of Information and Communications Technology 4-2-1, Nukui-Kitamachi, Koganei, Tokyo, 184-8795, Japan
大野 裕之 国立研究開発法人情報通信研究機構〒184-8795 東京都小金井市貫井北町4-2-1
Fax: +81 42 327 7941
EMail: hohno@ohnolab.org
Jun Murai Keio University 5322 Endo, Fujisawa Kanagawa 252 Japan
Jun Murai Keio University 5322 Endo, Fujisawa Kanagawa 252 Japan
Fax: +81 466 49 1101
EMail: jun@wide.ad.jp
Dan Wing 170 W. Tasman Drive San Jose, CA 95134 USA
Dan Wing 170 W. Tasman Drive San Jose, CA 95134 USA
Phone: +1 408 525 5314
EMail: 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
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.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ (http://www.ietf.org/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 (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。