summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2532.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2532.txt')
-rw-r--r--doc/rfc/rfc2532.txt675
1 files changed, 675 insertions, 0 deletions
diff --git a/doc/rfc/rfc2532.txt b/doc/rfc/rfc2532.txt
new file mode 100644
index 0000000..5aee63f
--- /dev/null
+++ b/doc/rfc/rfc2532.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+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.
+
+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. The
+
+
+
+Masinter & 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 of
+
+
+
+Masinter & 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 (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]).
+
+
+
+
+Masinter & Wing Standards Track [Page 3]
+
+RFC 2532 Extended Internet Fax March 1999
+
+
+2.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" in section 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 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.
+
+
+
+
+
+
+
+
+
+Masinter & Wing Standards Track [Page 4]
+
+RFC 2532 Extended Internet Fax March 1999
+
+
+2.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 see section 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 Capabilities
+
+ 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.
+
+
+
+
+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 note section 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 in section 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 (unlike section 3.2), and the information is acquired
+ automatically (unlike section 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 1999
+
+
+5. 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", 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.
+
+
+
+
+Masinter & Wing Standards Track [Page 9]
+
+RFC 2532 Extended Internet Fax March 1999
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masinter & Wing Standards Track [Page 10]
+
+RFC 2532 Extended Internet Fax March 1999
+
+
+8. 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.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Masinter & Wing Standards Track [Page 11]
+
+RFC 2532 Extended Internet Fax March 1999
+
+
+9. 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]
+