From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc3965.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc3965.txt (limited to 'doc/rfc/rfc3965.txt') diff --git a/doc/rfc/rfc3965.txt b/doc/rfc/rfc3965.txt new file mode 100644 index 0000000..0bc1565 --- /dev/null +++ b/doc/rfc/rfc3965.txt @@ -0,0 +1,787 @@ + + + + + + +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. + +Copyright Notice + + Copyright (C) The Internet Society (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. + + This document is a revision of RFC 2305. There have been no + technical changes. + +1. Introduction + + 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. + + + + + + +Toyoda, et al. Standards Track [Page 1] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + + 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. + + 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. + +1.1. Services + + 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. + +1.2. Cases + + 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 + + + + + + + +Toyoda, et al. Standards Track [Page 2] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + +1.3. Key Words + + 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]. + +2. Communication Protocols + + 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. + +2.1. Transport + + This section describes mechanisms involved in the transport between + IFAX devices. + +2.1.1. Relay + + Data transfer MAY be achieved using standard Internet mail transfer + mechanisms [1, 3]. The format of addresses MUST conform to the RFC + 821 and RFC 822 Internet mail standards [1, 2, + 3]. + +2.1.2. Gateway + + 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. + + + + + + + + + + + + + +Toyoda, et al. Standards Track [Page 3] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + + This specification describes the Internet mail service portion of + offramp addressing, confirmation and failure notification. Details + are provided in later sections. + +2.1.3. Mailbox protocols + + 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. + + 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. + +2.2. Formats + +2.2.1. Headers + + 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. + +2.2.2. MIME + + IFax devices MUST be compliant with MIME [4], except as noted in + Appendix A. + +2.2.3. Content + + 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. + +2.2.4. Multipart + + 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. + + + + + + +Toyoda, et al. Standards Track [Page 4] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + +2.3. Error Handling + +2.3.1. Delivery failure + + This section describes existing requirements for Internet mail, + rather than indicating special requirements for IFax devices. + + In the event of relay failure, the sending relay MUST generate a + failure message, which SHOULD be in the format of a 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.) + +2.3.2. Processing Failure + + 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.) + +3. Addressing + +3.1. Classic Email Destinations + + Messages being sent to normal Internet mail recipients will use + standard Internet mail addresses, without additional constraints. + +3.2. G3Fax Devices + + G3Fax devices are accessed via an IFAX offramp gateway, which + performs any authorized telephone dial-up. + +3.3. Address Formats Used by Offramps + + 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 + and [2, 3], as appropriate. + + 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). + + + + + +Toyoda, et al. Standards Track [Page 5] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + + The telephone number format SHOULD conform to [7, 8]. Other formats + MUST be syntactically distinct from [7, 8]. + +4. Image File Format + + 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. + + 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. + +5. Security Considerations + +5.1. General Directive + + 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. + +5.2. Threats and Problems + + 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. + +5.2.1. Spoofed Sender + + 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. + + 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. + + + + +Toyoda, et al. Standards Track [Page 6] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + + 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. + +5.2.2. Resources Consumed by Dialout + + 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. + + 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. + +5.2.3. GSTN Authorization Information + + 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. + + 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. + + + + + +Toyoda, et al. Standards Track [Page 7] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + + 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. + +5.2.4. Sender Accountability + + 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. + + 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. + +5.2.5. Message Disclosure + + 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. + + This expectation of privacy by G3Fax users SHOULD be preserved as + much as possible. + + Sufficient physical and software control may be acceptable in + constrained environments. The usual mechanism for ensuring data + confidentially entail encryption, as discussed below. + +5.2.6. Non Private Mailboxes + + 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]). + + + +Toyoda, et al. Standards Track [Page 8] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + +5.2.7. Traffic Analysis + + 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. + +5.3. Security Techniques + + There are two basic approaches to encryption-based security which + support authentication and privacy: + +5.3.1. Channel Security + + As with all email, an IFax message can be viewed as it traverses + internal networks or the Internet itself. + + 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. + + 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]. + +5.3.2. Object Security + + 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. + + 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]. + +6. References + +6.1. Normative References + + [1] Klensin, J., Editor, "Simple Mail Transfer Protocol", RFC 2821, + April 2001. + + [2] Resnick, P., Editor, "Internet Message Format", RFC 2822, April + 2001. + + + + + +Toyoda, et al. Standards Track [Page 9] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + + [3] Braden, R., "Requirements for Internet hosts - application and + support", STD 3, RFC 1123, October 1989. + + [4] Borenstein, N. and N. Freed, "Multipurpose Internet Mail + Extensions (MIME) Part Five: Conformance Criteria and Examples", + RFC 2049, November 1996. + + [5] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. + Rafferty, "File Format for Internet Fax", RFC 3949, November + 2004. + + [6] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD + 53, RFC 1939, May 1996. + + [7] Allocchio, C., "Minimal GSTN address format for Internet mail", + RFC 3191, October 2001. + + [8] Allocchio, C., "Minimal fax address format for Internet mail", + RFC 3192, October 2001. + + [9] Moore, K., and G. Vaudreuil, "An Extensible Message Format for + Delivery Status Notifications", RFC 3464, January 2003. + + [10] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part Two: Media Types", RFC 2046, November + 1996. + + [11] Moore, K. "MIME (Multipurpose Internet Mail Extensions) Part + Three: Message Header Extensions for Non-ASCII Text", RFC 2047, + November 1996. + + [12] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) - + image/tiff MIME Sub-type Registration", RFC 3302, September + 2002. + + [13] Bradner, S., "Key words for use in RFCs to Indicate Requirement + Levels", BCP 14, RFC 2119, March 1997. + +6.2. Informative References + + [14] Parsons, G. and J. Rafferty, "Tag Image File Format (TIFF) -- F + Profile for Facsimile", RFC 2306, March 1998. + + [15] ITU-T (CCITT), "Standardization of Group 3 facsimile apparatus + for document transmission", ITU-T (CCITT), Recommendation T.4. + + + + + + +Toyoda, et al. Standards Track [Page 10] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + + [16] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP + Message Format", RFC 2440, November 1998. + + [17] Kent, S. and R. Atkinson, "Security Architecture for the + Internet Protocol", RFC 2401, November 1998. + + [18] Hoffman, P., "SMTP Service Extension for Secure SMTP over + Transport Layer Security", RFC 3207, February 2002. + + [19] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC + 2633, June 1999. + +7. Acknowledgements + + 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. + + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Toyoda, et al. Standards Track [Page 11] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + +Appendix A: Exceptions to 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 recipients are not required to offer to put results in a file. + (Also see 2.3.2.) + + * IFax recipients MAY directly print/fax the received message rather + than "display" it, as indicated in RFC 2049. + +Appendix B: List of edits to 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" | + +----+----------+-------------------------------------------------+ + + + + +Toyoda, et al. Standards Track [Page 12] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + +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 + + + 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 + + + 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 + + Phone: +1 408 525 5314 + EMail: dwing@cisco.com + + + + + + + + + + + + + + + + +Toyoda, et al. Standards Track [Page 13] + +RFC 3965 A Simple Mode of Facsimile December 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (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. + + 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. + + 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. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Toyoda, et al. Standards Track [Page 14] + -- cgit v1.2.3