Applications Area Kiyoshi Toyoda INTERNET-DRAFT Hiroyuki Ohno Dec 21, 1997 Jun Murai Expires June 1998 WIDE Project Dan Wing cisco Facsimile over Internet Mail STATUS OF THIS MEMO This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Copyright (C) The Internet Society (1997, 1998). All Rights Reserved. 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 Fax [5,6]. It can send images not only to other Internet-aware fax devices but also to Internet-native systems, such as PCs with common email readers which can handle MIME mail and TIFF for Fax data. The specification facilitates communication among existing facsimile devices, Internet mail agents, and the gateways which connect them. The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [7]. 1 SCOPE This specification defines a message-based facsimile service over the Internet. It describes a minimum set of capabilities, taking into account those of a typical facsimile devices and PCs that can generate fax data. 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 the facsimile service that is operated over the public switched telephone network, so that gateways between the facsimile service 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 fax-capable device that uses T.30 [8] and the public switched telephone network (PSTN) is called a "G3Fax device" in this specification. An "IFax device" is compatible with T.30 and is Internet capable. 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 is forwarded via an IFax offramp gateway. A G3Fax device is a terminal that uses T.30 and the PSTN. 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 Onramp gateway(from => Network printer G3Fax) Onramp gateway(from => Offramp gateway (forward to G3Fax) G3Fax) Onramp gateway(from => Internet mail G3Fax) Onramp gateways pose a special problem with respect to addressing, since the G3Fax service which originates a document does not have a standard mechanism capable of generating Internet mail addresses. This specification presumes that individual onramp services will satisfy the requirement for generation of valid Internet mail addresses but does not consider the mechanism(s) to be used. 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 Relaying 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.30/PSTN fax service. Gateways can service multiple T.30/PSTN fax service users or can service only one. In the former case, they serve as an "mail transfer agent" and in the latter as a "mail user agent". An onramp is a gateway which connects from T.30/PSTN fax to Internet mail. An offramp is a gateway which connects from Internet mail to T.30/PSTN fax. This specification describes the Internet mail service portion of offramp addressing, confirmation and failure notification. Details are provided in later sections. Onramps are required to generate valid Internet mail address, header and MIME formats and to conform to the content requirements specified here. No other consideration to onramp gateways is provided. 2.1.3 Mailbox protocols Offramp gateways that serve multiple users SHOULD use SMTP; gateways that only serve a single mail recipient MAY use a mailbox access protocol such as POP or IMAP [9, 10]. 2.2 Formats 2.2.1 Headers IFax devices MUST be compliant with RFC 822 and its updates, which define the format of mail headers. The header of an IFax message SHOULD include Message-ID and MUST include all required fields, such as DATE and FROM [2]. 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 the F profile of TIFF for Fax[6]. Rules for the use of TIFF for Fax, for the message-based Internet fax 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 IFax fails the entire message, per [Processing failure] below. 2.3 Error Handling 2.3.1 Delivery failure In the event of delivery failure, the recipient MUST generate a failure message, which SHOULD be in the format of a DSN. [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] 2.3.2 Processing failure 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. 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 required telephone dial-up. 3.3 Address Formats for Offramps When a G3Fax device is identified by a telephone number, the G3Fax device's entire address, including the number and offramp host reference MUST be contained within standard Internet mail transport fields, such as RCPT TO and MAIL FROM [1]. The address MAY be contained within message content fields, such as and [2] as appropriate. The telephone number format SHOULD conform with [11,12]. 4 IMAGE FILE FORMAT IFax devices MUST be able to read and write minimum set TIFF files, per the rules for creating minimum set TIFF files defined in the F profile of TIFF for Fax [6], which is also compatible with the specification in [5]. A sender SHOULD NOT use TIFF fields and values beyond the minimum subset of TIFF for Fax 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. Any security to be provided MUST be part of the Internet security infrastructure, rather than creating new mechanisms or using other mechanisms 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 transport header. 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. 5.2.2 Cost to dialout In addition to the cost of email (CPU cycles and disk), offramp fax causes an outdial which often has a direct cost. Techniques for establishing authorization of the sender are essential to offramp facsimile services which are not funded through advertising, public funds, or other mechanisms not tied to the limitation of access. Due to the cost of dialout, unsolicited email which causes an outdial can be especially problematic. 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 PSTN 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. 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 fax message. Email From addresses are trivial to fake, so that using only the MAIL FROM [1] or >From [2] header is not sufficient. Offramps SHOULD provide a cover page notice or "for complaints please call ...." field specifying the telephone number to call when there is a problem. 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 fax, 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]). 5.2.7 Traffic analysis Eavesdropping of senders and recipients is easier on the Internet than PSTN. 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) 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. 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, such as PGP-MIME [13], can be used to provide end-to-end encryption. 6 REFERENCES [1] Postel, J. "Simple Mail Transfer Protocol", STD xx, RFC 821, August 1982. [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August l982. [3] Braden, R., 1123 "Requirements for Internet hosts - application and support", RFC 1123, October 1989. [4] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet mail Extension) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 2049, November 1996. [5] Parsons, G. and Rafferty, J. "Tag Image File Format(TIFF)-Application F", RFC XXXX, January 1998 [6] McIntyre, L., Zilles, S, et al. "File Format for Internet Fax", RFC XXXX, January 1998. [7] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [8] ITU-T (CCITT), "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", ITU-T (CCITT), Recommendation T.30, July, 1996 [9] J. Myers, M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [10] Crispin, M., "Internet Message Access Protocol Version 4/Rev1". RFC 2060, December 1996. [11] C. Allocchio, "Minimal PSTN address format for Internet mail". RFC XXXX, January 1998. [12] C. Allocchio "Minimal fax address format for Internet mail". RFC XXXX, January 1998. [13] Elkins, M., "MIME Security with Pretty Good Privacy (PGP)". RFC 2015, October 1996. [14] Moore, K. & Vaudreuil , G., "An Extensible Message Format for Delivery Status Notifications". RFC 1894, January 1996. [15] K. Moore, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996 [16] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First Virtual Holdings, November 1996. [17] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Representation of Non-ASCII Text in Internet Message Headers", RFC 2047, University of Tennessee, November 1996. [18] Atkinson, R., "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, August 1995. 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. 8 AUTHORS' ADDRESSES 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 9 FULL COPYRIGHT STATEMENT Copyright (C) The Internet Society (1997, 1998). All Rights Reserved. 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. 10 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. * IFax recipients MAY directly print/fax the received message rather than "display" it, as indicated in RFC 2049.