Fax Working Group Larry Masinter Internet Draft Xerox Corporation May 27, 1998 13:49PDT Dan Wing Expires November 1998 Cisco Systems draft-ietf-fax-eifax-01.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, GSTN billing information, 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) * GSTN billing information (Section 5) (optional) * Confidentiality (Section 6) (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 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 EIFax requirements This section defines requirements for devices that are to be considered EIFax compliant. 2.2.1 EIFax Sender Requirements An EIFax sender MUST request successful DSN (NOTIFY=SUCCESS) from the mail transfer agent to which the message is being submitted, if that transfer agent supports DSN. An EIFax sender (or, more precisely, the return address supplied by the EIFax sender) MUST be prepared to accept and display to the sending user the various states of DSN that will be returned, including the possibility that the message was relayed to a MTA that does not support DSN, as well as receiving a status message that is not in DSN format. An EIFax sender MAY also request MDNs, using the mechanism described in Section 2 of [RFC2298]. 2.2.2 EIFax Recipient Requirements An EIFax message may be received by software compliant with this document, or may be received by software that provides fewer features such as a legacy MTA or MUA. An EIFax recipient that acts as a SMTP server MUST support [RFC1891]. Other EIFax recipients that perform the function of a MTA SHOULD also support the sending of delivery status notifications. All delivery status notifications generated by an EIFax recipient MUST be in the format described in [RFC1894]. An EIFax recipient that performs message disposition SHOULD support the return of Message Disposition Notifications [RFC2298] following the guidelines for generation of MDNs in that document. While a user agent is "free to silently ignore" a request for a message disposition notification ([RFC 2298] section 2.1), in the case of a network printer which automatically prints messages it receives or an offramp gateway which automatically forwards such messages, the delivery status "dispatched" combined with disposition mode "automatic-action" SHOULD be sent. 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 otehr 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. GSTN Billing Information [RFC2305] recommends that an offramp gateway servicing multiple mailboxes use SMTP as its protocol. To provide billing information for the offramp service back to the originator of a message, the offramp gateway SHOULD implement [DSN-EXTENSIONS]. 6. 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. 6.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]. 6.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. 6.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. 6.2 Connections To secure the connection itself, including the envelope itself, EIFax devices should implement [AUTH] or IPSsec [IPSEC]. 6.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. 7. 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. 8. References [AUTH] J. Myers, "SMTP Service Extension for Authentication", draft-myers-smtp-auth-11.txt, Internet Draft, Work in Progress, February 1998. [DSN-EXTENSIONS] D. Wing. "Extensions to Delivery Status Notifications for Fax", Internet Draft, Work in Progress, November, 1997. [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-01.txt, March 1998. [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-00.txt, March 1998. [FEATURES] K. Holtman, A. Mutz, T. Hardie, "Feature Tag Registration Procedures", Internet Draft, Work in Progress, draft-ietf-conneg-feature-reg-00.txt, March 1998. [GOALS] L. Masinter, "Terminology and Goals for Internet Fax", Internet Draft, Work in Progress, draft-ietf-fax-goals-02.txt, March 1998. [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-02.txt, Feb 1998. [SMIME] B. Ramsdell. "S/MIME Version 3 Message Specification", Internet Draft, Work in Progress, draft-ietf-smime-msg-04.txt, May 1998. 9. 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. 170 West Tasman Drive San Jose, CA 95134-1619 Phone: +1 408 526 4000 Fax: +1 408 457 5208 EMail: dwing@cisco.com 10. 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.