Applications Area Dan Wing Internet Draft Cisco Systems, Inc. November 11, 1997 Expires May 1998 Scenerios for Delivery of FAX messages over SMTP draft-ietf-fax-scenerios-00.txt 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 Notice Copyright (C) The Internet Society (1997). All Rights Reserved. 1. Abstract This document describes various fax-over-SMTP implementation and deployment scenerios and some of the problems inherient with various solutions. Most of these scenerios have been described and discussed on the IETF-FAX mailing list. Wing Expires May 1998 [Page 1] Internet Draft Scenerios for FAX over SMTP November 1997 2. Table of Contents 1. Abstract 2. Table of Contents 3. Introduction 3.1. Definitions 3.2. Discussion of this Draft 4. Scenerios 4.1. Onramp: Legacy FAX to SMTP 4.1.1. Redialer 4.1.2. FAX Replacement 4.2. Offramp: SMTP to Legacy FAX 4.3. Combinations 4.3.1. Legacy to Legacy 4.3.2. SMTP to SMTP 5. Interaction of fax with existing SMTP infrastructure 5.1. Large messages 5.2. Firewalls 5.3. Gateways to non-SMTP mail systems 5.4. Intermittent connection to the Internet 5.5. Streaming 5.5.1. Streaming and message authentication 5.6. Delays 5.6.1 Transmission delays 5.6.2. Read delays 5.6.3. Delivery receipts 5.6.4. Capabilities exchange 5.6.4. Use of NOTIFY=DELAY 6. Security Considerations 7. Acknowledgments 8. References 9. Copyright 10. Author's Address 3. Introduction Many possible scenerios exist for fax-over-SMTP. Perhaps most important is the ability to receive from, and send to, a legacy fax machine which is connected to the PSTN. In addition it is desirable to send a fax image between two users on email. This document describes how an onramp and offramp device might function with the existing SMTP infrastructure, especially when these devices cannot perform normal "storing" of email as part of SMTP "store and forward" messaging. Onramp and offramp devices might be implemented as part of a Wing Expires May 1998 [Page 2] Internet Draft Scenerios for FAX over SMTP November 1997 multitasking server, such as Unix or Windows NT, with an integrated SMTP client/server, disk drive, and directory, dialplan, and alias lookup functions. Onramp and offramp boxes might also be implemented inside fax machines, multifunction devices, or might be "bump-in-the-wire" devices and have no disk drive (to minimize cost and increase MTBF). This document is a companion to the "Requirements for Internet Fax" [FAQ-REQ] document. 3.1. Definitions This document uses several terms which aren't in common use. onramp: A device which receives an incoming fax call, translates the fax image to TIFF-F, and can send the message to an SMTP server. An onramp can be diskless and have limited memory capacity. offramp: A device which receives an SMTP message in TIFF-F format and calls a fax machine, translates the TIFF-F message to a fax image, and transmits the fax image to the remote fax machine. An offramp can be diskless and have limited memory capacity. PSTN: Public Switched Telephone Network. redialer: A "bump-in-the-cord" device which sits between a fax machine and the PSTN and dials a pre-programmed number whenever the fax machine dials a number. When the remote system answers, the redialer sends the remote system the phone numbers that were originally sent by the fax machine. TIFF-F: File format for interchange of FAX images, described in [TIFF-F]. 3.2. Discussion of this Draft This draft is being discussed on the "ietf-fax" mailing list. To subscribe, send a message to: ietf-fax-request@imc.org with the line: subscribe in the body of the message. Archives are available from http://www.imc.org/ietf-fax. 4. Scenerios Wing Expires May 1998 [Page 3] Internet Draft Scenerios for FAX over SMTP November 1997 Three primary scenerios are discussed. a. Onramp: Legacy fax to SMTP b. Offramp: SMTP to legacy fax c. Combinations 4.1. Onramp: Legacy FAX to SMTP Several scenerios exist for causing the transmission from a legacy fax machine to be sent through SMTP. Once the transmission is an SMTP message, the message can then be sent to another fax machine or to a user's SMTP mailbox. 4.1.1. Redialer This situation would normally occur if the sender (who owns the legacy fax machine) joins a service which delivers FAXes to a user's mailbox. This might be useful to provide a familiar user experience to the sender [legacy fax] -> [redialer] -> [PSTN] -> [onramp] -> [SMTP] Redialer boxes are made by manufacturers like [MITEL] and [TELKOM]. 4.1.2. FAX Replacement Here the recipient has replaced their fax machine with an onramp. This might be done to automate fax distribution via T.30 subaddresses, a human, , or other methods to decide the ultimate desination of an incoming fax. [legacy fax] -> [PSTN] -> [onramp] -> [SMTP] 4.2. Offramp: SMTP to Legacy FAX An SMTP message can be sent to a legacy fax device via an offramp. This offramp could be on-premisis, built into a mailer, or could be a service provided by an Internet Service Provider. [SMTP] -> [offramp] -> [PSTN] -> [legacy fax] Wing Expires May 1998 [Page 4] Internet Draft Scenerios for FAX over SMTP November 1997 4.3. Combinations The above scenerios can be combined to provide other delivery scenerios. 4.3.1. Legacy to Legacy By combining a solution from section 3.1 with 3.2, it is possible to deliver from legacy fax to legacy fax. 4.3.2. SMTP to SMTP By making the onramp device a PC running normal messaging software (such as Netscape, IE, or Eudora), and the offramp a normal SMTP/POP server, you can send a fax image from one SMTP user to another SMTP user. 5. Interaction of fax with existing SMTP infrastructure 5.1. Large messages [HOST-REQ] stipulates that a mail transfer agent (MTA) must support a maximum message size of at least 64Kb, but encourages implementors to not impose a limit if at all possible. Messages larger than 64K bytes MAY be truncated or returned to the sender. Implementations should consider solutions, such as message/partial [MIME-TYPES], to send messages in small enough parts to be transported by mailers that impose a size limit. As fax offramps must be presented with the message in its entirety: 1. The FAX offramp can be implemented as a POP3/IMAP4 client with support for message/partial (which requires the fax offramp know, a priori, which 'users' it must check mail for), or, 2. an MTA 'close' to the fax offramp must reassemble the message prior to presenting it to the fax offramp. [MIME-FAQ] also mentions large messages: "3.10) What's ESMTP, and how does it affect MIME? ESMTP (Extended Simple Mail Transfer Protocol) is a mechanism by which extensions to "traditional" (RFC 821) SMTP can be Wing Expires May 1998 [Page 5] Internet Draft Scenerios for FAX over SMTP November 1997 negotiated by client and server. The mechanism (RFC 1869) is open-ended; so far two extensions have been defined. Message size declaration (RFC 1870) offers a graceful way for servers to limit the size of message they are prepared to accept. (With SMTP, the only possibility is for the server to discard the message after it has been sent in its entirety. There is no way for the client to know that it was the size of the message that caused the problem.) When a message is returned to the user as being too large to deliver, one possible approach might be to fragment the message using the MIME Message/Partial mechanism, and resubmit it. Depending on the exact reason for the "too large" rejection, this may or may not be a good idea. For example, the limitation may reflect the recipient's disk quota, in which case the fragmented message will not be fully deliverable either. The possibility of fragmentation should, therefore, be left to the user's discretion (not performed automatically by the SMTP client)." [...] 5.2. Firewalls Companies deploy firewalls to protect their internal networks from external networks, such as the Internet or other companies which are connected to their internal networks. Many firewalls impose restrictions on SMTP messages, as described in [FIREWALL-REQ]. Some firewall packages lack support for Delivery Status Notifications [SMTP-DSN], which Internet FAX intends to use for end-to-end delivery confirmation. However, as [MDN] is done with SMTP headers (and not 5.3. Gateways to non-SMTP mail systems With delivery of faxes as normal SMTP messages, these messages must be able to be transferred to non-SMTP mail systems, such as X.400, and proprietary mail systems such as Lotus cc:Mail, Microsoft Exchange, Wing Expires May 1998 [Page 6] Internet Draft Scenerios for FAX over SMTP November 1997 and DEC All-In-One. 5.4. Intermittent connection to the Internet POP3/IMAP - require knowing telephone number (as username) for login TURN, ETRN, [OD-RELAY]. 5.5. Streaming 5.5.1. Streaming and message authentication FAX onramp and offramp devices aren't expected to have a disk drive, and thus must stream their fax (and SMTP) data. Message authentication methods such as [PGP-MIME] and [SMIME] provide the signature at the end the message, which is too late for an offramp device to determine that a message has failed authentication. 5.6. Delays Today, fax provides immediate delivery. When a fax is being transmitted, users know the fax is being printed on the remote end, and often times users will call the recipient to tell them "the document is on your fax machine". Delays over SMTP are common, and some of them are enumerated below. 5.6.1 Transmission delays SMTP causes arbitrary transmission delays which are entirely dependent on the availability of an MTA in the SMTP 'path', the availability of the recipient's SMTP server which stores the message in the user's mailbox, and network outages, among other factors. 5.6.2. Read delays Today, most users read their mail using products such as Netscape, Internet Explorer, and Eudora. These products use the POP3 protocol to read messages, and SMTP to send messages. New versions of these products support IMAP4, a replacement for POP3. Currently, there is no mechanism for an SMTP server to indicate Wing Expires May 1998 [Page 7] Internet Draft Scenerios for FAX over SMTP November 1997 new mail has been received. Instead, the email software continually polls the POP server, typically every 5 to 10 minutes, to check for new mail. While users can usually configure their mail readers to check for mail more often, and can always force the mail reader to check for new messages by clicking a button on the user interface, users are not informed immediately when a new message arrives. This delay causes many people to erroneously believe that SMTP has an additional 5-10 minute "delay", and this belief will likely carry over to delivery of fax messages to user's SMTP mailboxes. Users that only check mail occasionally (because of a non-permanent connection to the Internet, for example) will not receive messages immediately. 5.6.3. Delivery receipts A delivery receipt (either generated by [DSN] or [MDN]) is subject to the same delays as a normal SMTP message. Thus if a message takes, on average, 3 minutes to be delivered to the recipient, the receipt should be expected to take at least 3 minutes to be sent to the originator of the message. 5.6.4. Capabilities exchange The delays described above would also occur with SMTP-based capabilities exchange as described in [ITU-FAX]. 5.6.4. Use of NOTIFY=DELAY [SMTP-DSN] provides a mechanism (NOTIFY=DELAY) which allows a sender to request a DSN if a message is "delayed". However, each SMTP implementation is free to decide on the definition of "delayed", thus such a request may not be useful unless the sender is aware of the definition of a "delayed" message by all MTAs in the SMTP 6. Security Considerations Security considerations are not (yet) described in this memo. Wing Expires May 1998 [Page 8] Internet Draft Scenerios for FAX over SMTP November 1997 7. Acknowledgments XXX 8. References [SMTP-DSN] K. Moore, "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996. [FIREWALL-REQ] N. Freed, K. Carosso, "An Internet Firewall Transparency Requirement", Internet Draft, Work in Progress, draft-freed-firewall-req-??.txt. [FAX-PROFILE] unknown, "FAX Profile for Internet Mail", Internet Draft, Work in Progress, draft-ietf-fax-profile-??.txt [FAX-REQ] L. Masinter, "Requirements for Internet FAX", Internet Draft, Work in Progress, draft-ietf-fax-requirements-??.txt. [HOST-REQ] R. Braden, "Requirements for Internet Hosts -- Application and Support", STD-3, RFC 1123, October 1989. [ITU-FAX] D. Crocker, "PROCEDURES FOR THE TRANSFER OF FACSIMILE DATA VIA INTERNET MAIL", Internet Draft, Work in Progress, draft-ietf-fax-itudc-??.txt. [MAIL] D. Crocker, "Standard for the Format of ARPA Internet Text Messages", STD-10, RFC 822, August 1982. [MDN] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", Internet Draft, Work in Progress, draft-ietf-receipt-mdn-??.txt. [MIME-FAQ] "comp.mail.mime frequently asked questions list", ftp://rtfm.mit.edu/pub/usenet/news.answers/mail/mime-faq/part3 [MIME-TYPES] N. Freed, N. Borenstein, "Multipurpose Internet Mail Extensions Wing Expires May 1998 [Page 9] Internet Draft Scenerios for FAX over SMTP November 1997 (MIME) Part Two: Media Types", RFC 2046, November 1996. [MITEL] Mitel Enterprises, http://www.mitel.com [OD-RELAY] R. Gellens, "On-Demand Mail Relay", Internet Draft, Work in Progress, draft-gellens-on-demand-??.txt. [PGP-MIME] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC2015, October 1996. [SMIME] S. Dusse, P. Hoffman, B. Ramsdell, L. Lundblade, L. Repka, "S/MIME Message Specification", Internet Draft, Work in Progress, draft-dusse-smime-msg-??.txt. [SMTP] J. Postel, "SIMPLE MAIL TRANSFER PROTOCOL", STD-10, RFC 821, August 1982. [SMTP-EXT] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker, "SMTP Service Extensions", STD-10, RFC 1869, November 1995. [SMTP-ENH-ERR] N. Freed, "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [TIFF-F] G. Parsons, J. Rafferty, "Tag Image File Format (TIFF) - Application F", Internet Draft, Work In Progress, draft-ietf-fax-tiff-??.txt. 9. Copyright Copyright (C) The Internet Society 1997. 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 implmentation 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 Wing Expires May 1998 [Page 10] Internet Draft Scenerios for FAX over SMTP November 1997 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. Author's Address 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 Wing Expires May 1998 [Page 11]