Movatterモバイル変換

Network Working Group                                        L. MasinterRequest for Comments: 2532                             Xerox CorporationCategory: Standards Track                                        D. Wing                                                           Cisco Systems                                                              March 1999Extended Facsimile Using Internet MailStatus 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.Abstract   This 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>.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.   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.  TheMasinter & Wing             Standards Track                     [Page 1]

RFC 2532                 Extended Internet Fax                March 1999   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].1.1.  Definition of Terms   The term "processing" indicates the action of rendering or   transmitting the contents of the message to a printer, display   device, or fax machine.   The term "processing confirmation" is an indication by the recipient   of a message that it is able to process the contents of that message.   The term "recipient" indicates the device which performs the   processing function.  For example, a recipient could be implemented   as a traditional Mail User Agent on a PC, a standalone device which   retrieves mail using POP3 or IMAP, an SMTP server which prints   incoming messages (similar to an LPR server).   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].1.2.  GSTN Fax Gateways ("onramp"/"offramp")   The behavior of gateways from GSTN fax to SMTP ("onramps") and from   SMTP to GSTN fax ("offramps") are not described in this document.   However, such gateways SHOULD have the behavior characteristics of   senders and recipients as described in this document.2.  Delivery and Processing Confirmation   In traditional GSTN-based realtime facsimile, the receiving terminal   acknowledges successful receipt and processing of every page [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 ofMasinter & Wing             Standards Track                     [Page 2]

RFC 2532                 Extended Internet Fax                March 1999   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.2.1.  Sender Requirements   Because delivery failure may occur (over disk quota, user no longer   exists, malconfigured mailer), a delivery failure message (in the   format described by [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.2.1.1.  Delivery Confirmation   If the sender desires delivery confirmation, the sender MUST request   Delivery Status Notification by including the the esmtp-keyword   NOTIFY with the esmtp-value SUCCESS (section 5.1 of [RFC1891]).2.1.2.  Processing Confirmation   If the sender desires processing confirmation, the sender MUST   request Message Disposition Notification ([RFC2298] section 2) when   sending the message itself.   Because a recipient may silently ignore a request for an MDN (section2.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 (section2.1 of [RFC2298]).Masinter & Wing             Standards Track                     [Page 3]

RFC 2532                 Extended Internet Fax                March 19992.2.   Recipient Requirements   Recipients SHOULD implement Message Disposition Notifications   [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" insection 5.2.2.1.  MDN Recipient Requirements   Recipients MUST be configurable to silently ignore a request for an   MDN (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.2.2.2.  Recipients Using Mailbox Access Protocols   A recipient using POP3 [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 theRFC822 "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 otherRFC822 or MIME fields for making   such determinations.Masinter & Wing             Standards Track                     [Page 4]

RFC 2532                 Extended Internet Fax                March 19992.3.  Messaging Infrastructure Requirements   This section explains the requirements of the SMTP messaging   infrastructure used by the 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.3.1.  Sender Infrastructure   Support for DSN [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 seesection 5.1 of this document.2.3.2.  Receiver Infrastructure   Support for DSN [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].3.  Additional Document CapabilitiesSection 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 inRFC 2301, in addition to profile S.  A recipient   which supports additional profiles SHOULD indicate this support as   persection 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.Masinter & Wing             Standards Track                     [Page 5]

RFC 2532                 Extended Internet Fax                March 1999   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 notesection 4.1 of this   document.3.1.  Sender Manual Configuration   One way a sender can send a document which exceeds the minimum subset   allowed by [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.3.2.  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.   There is active investigation within the IETF to develop a solution   to this problem, which would resolve a wide range of issues with   store-and-forward messaging.3.3.  Capabilities Returned in MDN or DSN   As outlined insection 2 of this document, a sender may request a   positive DSN or an MDN.Masinter & Wing             Standards Track                     [Page 6]

RFC 2532                 Extended Internet Fax                March 1999   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 (unlikesection 3.2), and the information is acquired   automatically (unlikesection 3.1).3.3.1.  Restrictions and Recommendations   A sender MUST NOT send a message with no processable content to   attempt to elicit an MDN/DSN capability response.  Doing so with a   message with no processable content (such as a message containing   only a request for capabilities or a blank message) will confuse a   recipient not already designed to understand the semantics of such a   message.   A recipient SHOULD indicate the profiles and features supported, even   if the recipient supports only Tiff Profile S (the minimum set for   fax as defined by [RFC2305]) [RFC2531].  This allows a sender to   determine that the recipient is compliant with this Extended   Facsimile Using Internet Mail specification.4. Security Considerations   As this document is an extension of [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.4.1.  Inaccurate Capabilities Information   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,   there SHOULD be a mechanism to allow the cached information to be   ignored or overridden if necessary.4.2.  Forged MDNs or DSNs   Forged DSNs or MDNs, as described in [RFC1892,RFC1894,RFC2298] can   provide incorrect information to a sender.Masinter & Wing             Standards Track                     [Page 7]

RFC 2532                 Extended Internet Fax                March 19995.  Implementation Notes   This section contains notes to implementors.5.1.  Submit Mailer Does Not Support DSN   In some installations the generally available submit server may not   support DSNs.  In such circumstances, it may be useful for the sender   to implement [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.5.2.  Recipient Recommendations   To provide a high degree of reliability, it is desirable for the   sender to know that a recipient could not process a message.  The   inability to successfully process a message may be detectable by the   recipient's MTA or MUA.   If the recipient's MTA determines the message cannot be processed,   the recipient's MTA is strongly encouraged to reject the message with   a [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].6.  Acknowledgements   The authors would like to acknowledge the members of the IETF   Internet Fax working group, and especially the following contributors   who provided assistance and input during the development of this   document:Masinter & Wing             Standards Track                     [Page 8]

RFC 2532                 Extended Internet Fax                March 1999   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.7.  References   [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",RFC1893, 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.Masinter & Wing             Standards Track                     [Page 9]

RFC 2532                 Extended Internet Fax                March 1999   [RFC2542] Masinter, L., "Terminology and Goals for Internet Fax",RFC2542, 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.Masinter & Wing             Standards Track                    [Page 10]

RFC 2532                 Extended Internet Fax                March 19998. Authors' Addresses   Larry Masinter   Xerox Palo Alto Research Center   3333 Coyote Hill Road   Palo Alto, CA 94304  USA   Fax:    +1 650 812 4333   EMail:  masinter@parc.xerox.com   Dan Wing   Cisco Systems, Inc.   101 Cooper Street   Santa Cruz, CA 95060  USA   Phone:  +1 831 457 5200   Fax:    +1 831 457 5208   EMail:  dwing@cisco.comMasinter & Wing             Standards Track                    [Page 11]

RFC 2532                 Extended Internet Fax                March 19999.  Full Copyright Statement   Copyright (C) The Internet Society (1999).  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.Masinter & Wing             Standards Track                    [Page 12]