Network Working Group L. Masinter Request for Comments: 2532 Xerox Corporation Category: Standards Track D. Wing Cisco Systems March 1999 Extended 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 (1999). All Rights Reserved.
AbstractThis document describes extensions to "Simple Mode of Facsimile Using Internet Mail" [RFC2305] and describes additional features, including transmission of enhanced document characteristics (higher resolution, color) and confirmation of delivery and processing. These additional features are designed to provide the highest level of interoperability with the existing and future standards-compliant email infrastructure and mail user agents, while providing a level of service that approximates the level currently enjoyed by fax users. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights in <http://www.ietf.org/ipr.html>. RFC2305] that may be combined to create an extended mode of facsimile using Internet mail. 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 existing standards for advanced functionality such as positive delivery confirmation and disposition notification. 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 standardizes the following two features. * Delivery confirmation (Section 2) (required) * Additional document features (Section 3) (optional) These features are fully described in another document titled "Terminology and Goals for Internet Fax" [RFC2542]. RFC2119]. T.30]. In Internet Mail, the operations of Delivery (to the mailbox) and Disposition (to paper or a screen) may be separated in time (due to store and forwarding of messages) and location (due to separation of delivery agent (MTA) and user agent (MUA)). The confirmation of
these two operations are supplied by two different standards-track mechanisms: Delivery Status Notifications (DSN) [RFC1891, RFC1894] and Message Disposition Notifications (MDN) [RFC2298], respectively. This section defines requirements for devices or services that are to be considered compliant with this document. RFC1894] or otherwise) may be sent to the envelope-from address specified by the sender. Thus, the envelope- from address supplied by the sender MUST be able to properly handle such delivery failure messages. section 5.1 of [RFC1891]). RFC2298] section 2) when sending the message itself. Because a recipient may silently ignore a request for an MDN (section 2.1 of [RFC2298]) at any time: * MDNs MUST NOT be used for delivery confirmation, but are only useful for disposition ("processing") notification. * the sender MUST NOT assume the recipient will respond to an MDN request in a subsequent message, even if the recipient has done so in the past. The address provided by the sender on the Disposition-Notification-To field MUST be able to receive Message Disposition Notifications messages [RFC2298] and SHOULD be able to receive messages that are not in the Message Disposition Notification format (due to the existence of legacy systems that generate non-RFC2298-compliant responses to the Disposition-Notification-To field). The Disposition-Notification-To address and the envelope-from address SHOULD match to allow automated responses to MDN requests (section 2.1 of [RFC2298]).
RFC2298] and SHOULD indicate supported media features in DSN and MDN messages per [RFC2530]. If the recipient is an SMTP server, it behaves as part of the receiver infrastructure and is therefore subject to the "Receiver Infrastructure" requirements of this document. See also "Recipient Recommendations" in section 5. section 2.1 of [RFC2298]). If the recipient is an automated message processing system which is not associated with a person, the device MAY be configurable to always respond to MDN requests, but in all cases MUST be configurable to never generate MDNs. A recipient MUST NOT generate an unsolicited MDN to indicate successful processing. A recipient MAY generate an unsolicited MDN (sent to the envelope-from (Return-Path:) address) to indicate processing failure, but subject to the [RFC2298] requirement that it MUST always be possible for an operator to disable unsolicited MDN generation. RFC1939] or IMAP4 [RFC2060] to retrieve its mail MUST NOT generate a Delivery Status Notification message [RFC1894] because such a notification, if it was requested, would have already been issued by the MTA on delivery to the POP3 or IMAP4 message store. The recipient MUST NOT use the RFC822 "To:" fields, "Cc:" fields, "Bcc:" fields, or any other fields containing header recipient information to determine the ultimate destination mailbox or addressee, and SHOULD NOT use other RFC822 or MIME fields for making such determinations.
RFC1891] MUST be provided by the mail submission server [RFC2476] used by the sender and MUST be provided up to the mailer responsible for communicating with external (Internet) mailers. Also see section 5.1 of this document. RFC1891] MUST be provided by the external (Internet-accessible) mailer, and MUST be provided by each mailer between the external mailer and the recipient. If the recipient is implemented as an SMTP server it MUST also support DSN [RFC1891]. Section 4 of "A Simple Mode of Facsimile Using Internet Mail" [RFC2305] allows sending only the minimum subset of TIFF for Facsimile "unless the sender has prior knowledge of other TIFF fields or values supported by the recipient." A recipient MAY support any or all (or any combination) of the TIFF profiles defined in RFC 2301, in addition to profile S. A recipient which supports additional profiles SHOULD indicate this support as per section 3.2 or 3.3 of this document. As a consequence, a sender MAY use those additional TIFF profiles when sending to a recipient with the corresponding capabilities. A sender SHOULD be able to recognize and process the feature tags as defined in [RFC2531] when reviewing the capabilities presented by a potential recipient. The capability matching rules indicated there (by reference to [RFC2533]) allow for the introduction of new features that may be unrecognized by older implementations. A sender MAY send a message containing both the minimum subset of TIFF for Facsimile (as specified in [RFC2305]) and a higher quality TIFF using multipart/alternative.
Three methods for the sender to acquire such knowledge are described: 1. Sender manual configuration 2. Capabilities in Directory 3. Capabilities returned in MDN or DSN Method (3) SHOULD be used. An implementation may cache capabilities locally and lose synchronization with the recipient's actual capabilities. A mechanism SHOULD be provided to allow the sender to override the locally-stored cache of capabilities. Also note section 4.1 of this document. RFC2305] is for the user controlling the sender to manually override the default settings, usually on a per-recipient basis. For example, during transmission a user could indicate the recipient is capable of receiving high resolution images or color images. While awkward and not automatic, this mechanism reflects the current state of deployment of configuration for extended capabilities to ordinary Internet email users. section 2 of this document, a sender may request a positive DSN or an MDN.
If the recipient implements [RFC2530], the DSN or MDN that is returned can contain information describing the recipient's capabilities. The sender can use this information for subsequent communications with that recipient. The advantage of this approach is that additional infrastructure is not required (unlike section 3.2), and the information is acquired automatically (unlike section 3.1). RFC2305]) [RFC2531]. This allows a sender to determine that the recipient is compliant with this Extended Facsimile Using Internet Mail specification. RFC2305], the Security Considerations section of [RFC2305] applies to this document. The following additional security considerations are introduced by the new features described in this document. 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, there SHOULD be a mechanism to allow the cached information to be ignored or overridden if necessary. RFC1892, RFC1894, RFC2298] can provide incorrect information to a sender.
RFC974] mail routing as well as additional submission server functions [RFC2476] so that the installation is not constrained by limitations of the incumbent submission server. RFC1893] status code of 5.6.1. This status code may be returned in response to the end-of-mail-data indicator if the MTA supports reporting of enhanced error codes [RFC2034], or after message reception by generating a delivery failure DSN ("bounce"). Note: Providing this functionality in the MTA, via either of the two mechanisms described above, is superior to providing the function using MDNs because MDNs must generally be requested by the sender (and the request may, at any time, be ignored by the receiver). Message rejection performed by the MTA can always occur without the sender requesting such behavior and without the receiver circumventing the behavior. If the message contains an MDN request and the recipient's MUA determines the message cannot be processed, the recipient's MUA is strongly encouraged to repond to an MDN request and indicate that processing failed with the disposition-type "processed" or "displayed" and disposition-modifier "error" or "warning" [RFC2298].
Vivian Cancio, Richard Coles, David Crocker, Ned Freed, Graham Klyne, MAEDA Toru, Geoff Marshall, Lloyd McIntyre, Keith Moore, George Pajari, James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford, and Greg Vaudreuil. [RFC2533] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999. [RFC2531] McIntyre, L. and G. Klyne, "Content Feature Schema for Internet Fax", RFC 2531, March 1999. [RFC2530] Wing, D., "Indicating Supported Media Features Using Extensions to DSN and MDN", RFC 2530, March 1999. [RFC1891] Moore, K. "SMTP Service Extensions for Delivery Status Notifications", RFC 1891, January 1996. [RFC1893] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, January 1996. [RFC1894] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 1894, January 1996. [RFC2034] Freed, N, "SMTP Service Extension for Returning Enhanced Error Codes", RFC 2034, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2298] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. [RFC2301] McIntyre, L., Zilles, S., Buckley, R., Venable, D., Parsons, G. and J. Rafferty, "File Format for Internet Fax", RFC 2301, March 1998. [RFC2305] Toyoda, K., Ohno, H., Murai, J. and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 2305, March 1998. [RFC974] Partridge. C., "Mail routing and the domain system", STD 14, RFC 974, January 1986. [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[RFC2542] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999. [T.30] "Procedures for Document Facsimile Transmission in the General Switched Telephone Network", ITU-T (CCITT), Recommendation T.30, July, 1996. [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996. [RFC2060] Crispin, M., "Internet Message Access Protocol - Version 4Rev1", RFC 2060, December 1996.