HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:20:12 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Fri, 14 Aug 1998 13:05:00 GMT ETag: "2ed965-57a0-35d435fc" Accept-Ranges: bytes Content-Length: 22432 Connection: close Content-Type: text/plain Fax Working Group Larry Masinter Internet Draft Xerox Corporation August 7, 1998 Dan Wing Expires January 1999 Cisco Systems draft-ietf-fax-eifax-03.txt Extended Facsimile Using 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 view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). This draft is being discussed by the IETF FAX working group. To subscribe to the mailing list, 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. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract This document describes extensions to 'Simple Mode of Facsimile Using Internet Mail' [RFC2305] to accomplish additional features, including transmission of enhanced document characteristics (higher resolution, color), confirmation of delivery, quick message delivery, and message confidentiality. Note: some features in this Internet Draft are being actively discussed in the Internet Fax working group and amongst experts in both facsimile and email. This document does not represent a final consensus of the working group, but is offered as a probable resolution of those discussions, based on current directions, as the proposals are believed to be consistent with the goals of Internet Fax as well as current standards-track directions for email protocols. 1. Introduction This document notes a number of enhancements to the "Simple Mode of Facsimile Using Internet Mail" [RFC2305] that may be combined to create an extended mode of facsimile using Internet mail. To promote interoperability, the new features are designed to be interoperable with the existing base of mail transfer agents (MTAs) and mail user agents (MUAs), and take advantage of standards-track mechanisms for positive delivery and disposition notifications. Thus, the enhancements described in this document utilize the messaging infrastructure, where possible, instead of creating fax-specific features which are unlikely to be implemented in non-fax messaging software. This document describes a protocol suite that satisfies all of the required and highly desirable features identified in [GOALS]: * Delivery confirmation (Section 2) (required) * Additional document features (Section 3) (optional) * Quick delivery and confirmation (Section 4) (optional) * Confidentiality (Section 5) (optional) A device which supports all of these recommendations is called an EIFax (Extended Internet Fax) device. 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 [RFC2119]. 2. Delivery and Processing Confirmation 2.1. Background This section explains the background of delivery confirmation for facsimile and Internet mail as a justification for the protocol requirements made in section 2.2. In traditional facsimile, the sending terminal receives a confirmation when the receiving terminal has finished processing the incoming fax. In Internet Mail, the operations of Delivery (to the mailbox) and Disposition (to paper or a screen) may be separated in time and location. The confirmation of these two operations are supplied by two different standards-track documents, Delivery Status Notifications (DSN) [RFC1891, RFC1894] and Message Disposition Notifications (MDN) [RFC2298] respectively. a) how they are requested: Delivery status notifications are requested within the SMTP protocol using SMTP extensions [RFC1891], while disposition notifications are requested by including a Disposition-Notification-To header in the message. b) when they are reported: Delivery status is reported when a message is delivered to some repository or end-point under the control of the recipient. Disposition notification (MDN) is provided when the message is disposed of by the recipient user, either manually or automatically. c) which agent reports them: Delivery status is reported by the mail transport mechanism, while disposition is reported by the end mail user agent. d) what form the reports take: Both DSNs and MDNs are sent in a "multipart/report". DSNs use "report-type=delivery-status"; MDNs use "report-type=disposition-notification". e) the requirement for notification: The standards for MDNs and DSNs differ on the requirement for automatically generating them. The generation of MDNs by any recipient is entirely optional, and thus no sender can rely on obtaining a MDN from an arbitrary recipient. The generation of some kind of DSN (if only a 'relayed' message) is required and a standard part of MTA operation. 2.2. Confirmation Requirements This section defines requirements for devices or services that are to be considered compliant with the delivery and processing confirmation section of this memo. 2.2.1. EIFax Sender Requirements 2.2.1.1. Delivery Confirmation If the sender wishes to receive a delivery confirmation or an indication that delivery confirmation is not possible, an EIFax sender MUST request a DSN [RFC1891] from its mail submission server [SUBMIT] (MTA) using the RCPT command with the esmtp-keyword NOTIFY and including esmtp-keyword SUCCESS. Other esmtp-keywords such as DELAY and FAILURE may also be requested if the sender wishes to receive notification of delivery delays or delivery failures. The envelope-from address provided by the EIFax sender MUST be able to receive all types of Delivery Status Notifications [RFC1894] and be able to receive delivery failure or delayed delivery messages that are not in the Delivery Status Notification format [RFC1894]. 2.2.1.2. Processing Confirmation If an EIFax sender wishes to receive processing confirmation and the final recipient is a Mail User Agent, the EIFax sender MUST request an MDN [RFC2298]. If an EIFax sender wishes to receive processing confirmation and the final recipient is a fax offramp implemented as an MTA, the fax offramp will generate processing confirmation in the absense of an MDN request, so an MDN request is not necessary. If an EIFax sender wishes to receive processing confirmation and is unaware of the recipient's implementation, the EIFax sender SHOULD request an MDN. NOTE: Because a request for an MDN can be silently ignored [section 2.1 of RFC2298], MDNs MUST NOT be used for delivery confirmation, but are only useful for determining if a message was processed. In all cases MDNs are optionally sent by the recipient. NOTE: Receipt of an MDN MUST NOT be construed as any indication that an MDN will be sent in response to another message requesting an MDN. The address provided by the EIFax sender on the Disposition-Notification-To field MUST be able to receive Message Disposition Notifications messages [RFC2298] and be able to receive messages that are not in the Message Disposition Notification format (due to the existence of legacy systems that utilize the same header but do not generate RFC2298-compliant responses). 2.2.2. EIFax Recipient Requirements All EIFax recipients SHOULD implement MDN [RFC2298], and SHOULD implement Fax Extensions for DSN and MDN [REPORT-EXTENSIONS], and MUST be configurable to silently ignore a request for an MDN ([section 2.1 of RFC2298]). 2.2.2.1. Fax Offramp Requirements A "Fax Offramp" is defined as a device that obtains a message and connects to a fax machine, communicates using the fax protocol to that fax machine, and transmits the message to that fax machine. 2.2.2.1.1. Fax Offramps Implemented as SMTP Servers MUST implement Delivery Status Notifications [RFC1891 through RFC1894], and SHOULD implement Fax Extensions for DSN and MDN [REPORT-EXTENSIONS]. If a successful DSN was requested and an MDN was requested, the MDN SHOULD NOT be sent -- only the DSN needs to be sent. The offramp MUST NOT use anything but the RFC821 envelope-to field to make any decision about the actual telephone number to dial. 2.2.2.1.2. Fax Offramps Implemented as POP/IMAP Clients MUST NOT generate a Delivery Status Notification message [RFC1894]. The offramp MUST NOT use anything but the POP/IMAP username to map to a single telephone number. For example, it MUST NOT use any RFC822 field or information within the message body or MIME parts to make any decision about the telephone number to dial. 2.2.3. EIFax Messaging Infrastructure Requirements This section explains the requirements of the SMTP messaging infrastructure used by the EIFax sender and receiver. This infrastructure is commonly provided by the ISP or a company's internal mailers but can actually be provided by another organization with appropriate service contracts. 2.2.3.1. Sender Infrastructure Support for DSN [RFC1891] MUST be provided by the mail submission server [SUBMIT] used by the EIFax sender, and SHOULD/MUST (?) be provided up to the mailer responsible for communicating with external (Internet) mailers. 2.2.3.2. Receiver Infrastructure Support for DSN [RFC1891] SHOULD/MUST (?) be provided by the external (Internet-accessible) mailer, and SHOULD/MUST (?) be provided by each mailer between the external mailer and the EIFax recipient. 3. Additional document capabilities Section 4 of [RFC2305] only allows sending the minimum subset of TIFF for Facsimile "unless the sender has prior knowledge of other TIFF fields or values supported by the recipient." Various methods for the sender to aquire such knowledge have been proposed: 1. Sender manual configuration 2. Message Disposition Notification Extension 3. Capabilities in Directory 3.1 Sender manual configuration One way a sender can send a document which exceeds the minimum subset allowed by [RFC 2305] is for the user controlling the sender to manually override the default settings, at least for particular recipients. If there were well-known configurations with combined capabilities, those capabilities could be described in the sender's user interface. For example, a vendor or trade association could create a profile of recipient capabilities that would describe an extended set of TIFF features and image sizes, and then the sender could manually be configured to send such files if the user controlling the sender knows of the recipient capabilities. For example, a trade association could create a profile named "SuperInterFax", which would signify the ability to accept TIFF profiles M, P, and F and any TIFF resolution and media size. With this profile, a user could manually decide to send a "SuperInterFax" to an address that was advertised to accept this profile. While awkward, this mechanism reflects the current state of deployment of configuration for extended capabilities to ordinary Internet email users. 3.2 Message Disposition Notification Extension As outlined in section 2.2.1, an EIFax sender MAY request a Message Disposition Notification. If the recipient supports responding to such a message, and the recipient authorizes responding to the MDN request, the recipient's MDN MAY contain information describing the recipient's capabilities as described in [MDN-FEATURES]. EIFax senders MAY retain a local cache of information about the features supported by recipients. When an EIFax device sends a message to a specific recipient, it MAY use cached information to determine the recipient's capabilities to handle extended document features such as defined in [MDN-FEATURES]. 3.3 Capabilities in Directory A future direction for enhanced document features is to create a directory structure of recipient capabilities, deployed, for example, through LDAP or DNS. The directory would provide a mechanism by which a sender could determine a recipient's capabilities before message construction or transmission, using a directory lookup. Such mechanisms are not defined in this document. 4. Quick Delivery and Confirmation [SESSION] describes a method by which delivery confirmation may be delivered quickly if there is a direct connection between sender and recipient. EIFax devices SHOULD implement [SESSION]. Intermediate MTAs, e.g., as part of firewalls, MAY also act as [SESSION] gateways, allowing for immediate delivery, with fallback to store-and-forward. EIFax devices MAY implement standard Internet mail routing using the domain name system [RFC974]. EIFax devices MAY be SMTP recipients registered as the primary mail exchanger for their domain. This combination will allow the sending EIFax device to communicate directly with the recipient device. 5. Security Many uses of Internet Fax require greater security; the requirements for security are discussed in [GOALS]. EIFax supports security by providing for secured content and connections. 5.1 Content To secure the contents of the message itself, EIFax devices SHOULD implement S/MIME [SMIME] or PGP-MIME [PGPMIME] or both; these systems are based on the security framework for MIME [MIME-SECURE]. 5.1.1 Authentication EIFax devices SHOULD use the multipart/signed MIME type using S/MIME or PGP-MIME signed messages. An EIFax SHOULD sign each message with the identity of the originating user or with the identity of the originating machine or service. An EIFax sender MAY choose its method of signing a message. An EIFax recipient SHOULD verify the signature of all received messages and indicate in any particular way whether the message is unsigned, signed with an unverifiable signature, signed with a signature that does not verify, or signed with a verified signature. 5.1.2 Privacy Using the methods of [MIME-SECURE], an EIFax device MAY use either S/MIME [SMIME] or PGP-MIME [PGPMIME] to envelope the content of a document. Enveloping MAY be applied either before or after signing. Enveloped data should only be sent if the recipient's capability to decode the enveloped data is known. 5.2 Connections To secure the connection itself, including the envelope itself, EIFax devices should implement [AUTH] or IPSsec [IPSEC]. 5.3 When to use security The capability to perform secure transfer is discovered by a sender either through a manual process or by discovering the public key of the recipient. Senders may unilaterally send multipart/signed documents using the signature method of their choice. 6. Security considerations [RFC2305] describes the security environment of facsimile and the considerations. This memo extends the requirements of RFC 2305 to specifically recommend the use of both PGP and S/MIME. Inaccurate capability information (section 3) could cause a denial of service. The capability information could be inaccurate due to many reasons, including compromised or improperly configured directory server, improper manual configuration of sender, compromised DNS, or spoofed MDN. If a sender is using cached capability information, it SHOULD be manually confirmed by a user before it is automatically used. 7. Implementation Notes 7.1 POP Clients and Message Disposition Notifications If multiple POP clients are accessing the same mailbox the POP clients MUST be configurable to leave mail on server (LMOS). This is because the MDN specification permits only one response [section 2.1, RFC2298], and because POP doesn't include a mechanism to indicate if an MDN has already been generated by a POP client. 8. Acknowledgements The authors would like to acknowledge the members of the IETF-FAX working group, and especially the following contributors who provided assistance in creating to this document. In alphabetical order: Vivian Cancio, Xerox Richard Coles, Lockheed Martin David Crocker, Brandenburg Consulting Ned Freed, Innosoft Graham Klyne, Integralis Ltd. Geoff Marshall, ___ Keith Moore, University of Tennessee George Pajari, Faximum Software Inc. James Rafferty, Human Communications Richard Shockey, Shockey Consulting LLC Brian Stafford, Office Logic Maeda Toru, Canon ((Is this complete? Please email dwing@cisco.com if your name was omitted, or your company name is incorrect)) 9. References [AUTH] J. Myers, "SMTP Service Extension for Authentication", Internet Draft, Work in Progress, draft-myers-smtp-auth-XX.txt, February 1998. [REPORT-EXTENSIONS] D. Wing, "Fax Extensions to DSN and MDN", Internet Draft, Work in Progress, draft-ietf-fax-report-extensions.txt. [MDN-FEATURES] L. Masinter and D. Wing, "Using Message Disposition Notifications to Indicate Supported Features", Internet Draft, Work in Progress, draft-ietf-fax-mdn-features-XX.txt. [MEDIA] "Media Features for Display, Print, and Fax", L. Masinter, K. Holtman, A. Mutz, D. Wing, Internet Draft, Work in Progress, draft-ietf-conneg-media-features-XX.txt. [FEATURES] K. Holtman, A. Mutz, T. Hardie, "Feature Tag Registration Procedures", Internet Draft, Work in Progress, draft-ietf-conneg-feature-reg-XX.txt. [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt. [RFC1825] R. Atkinson, "Security Architecture for the Internet Protocol", RFC 1825, Naval Research Laboratory, August 1995. [RFC1847] "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995. [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status Notifications", RFC 1891, January 1996. [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996 [RFC2015] M. Elkins, "MIME Security with Pretty Good Privacy (PGP)", RFC2015, October 1996. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [RFC2298] R. Fajman, "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. [RFC2301] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998. [RFC2305] K.Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. [RFC974] C. Partridge. "Mail routing and the domain system", RFC 974, January 1986. [SESSION] N. Joffe, D. Wing, L. Masinter, "SMTP Service Extension for Immediate Delivery", Internet Draft, Work in Progress, draft-ietf-fax-smtp-session-XX.txt. [SMIME] B. Ramsdell. "S/MIME Version 3 Message Specification", Internet Draft, Work in Progress, draft-ietf-smime-msg-XX.txt. [SUBMIT] R. Gellens, J. Klensin, "Message Submission", Internet Draft, Work in Progress, draft-gellens-submit-XX.txt. 10. Authors' Addresses Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 USA Fax: +1 415 812 4333 EMail: masinter@parc.xerox.com Dan Wing Cisco Systems, Inc. 101 Cooper Street Santa Cruz, CA 95060 Phone: +1 408 457 5200 Fax: +1 408 457 5208 EMail: dwing@cisco.com 11. Copyright Copyright (C) The Internet Society 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.