GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2532

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2532.txt · Last modified: 1999/03/11 23:10 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki