Internet Fax Working Group                                Larry Masinter
Internet Draft                                         Xerox Corporation
September 30, 1998                                              Dan Wing
Expires March 1999                                         Cisco Systems

                 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 (Africa),
   (Northern Europe), (Southern Europe),
   (Pacific Rim), (US East Coast), or
   (US West Coast).

   This draft is a product of the IETF Internet Fax working group.  To
   subscribe to the mailing list, send a message to with the line "subscribe" in the body of the
   message.  Archives are available from

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.


   This document describes extensions to 'Simple Mode of Facsimile Using
   Internet Mail' [RFC2305] and provides 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.

Masinter, Wing            Expires January 1999                 [Page 1]

Internet Draft           Extended Internet Fax            September 1998

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 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

   This document standardizes two features described in its companion
   document, [GOALS]:

     *  Delivery confirmation (Section 2) (required)
     *  Additional document features (Section 3) (optional)

1.1.  Definition of terms

   The term "processing" indicates the ability to successfully render or
   successfully transmit the contents of the message to a printer, on a
   display device, or to a fax machine.

   The term "recipient" indicates the device which processes the content
   of the mail message and renders it to the user by transmitting it to
   a remote fax machine, printer, displaying it on a terminal.  For
   example, a recipient could be implemented as a traditional Mail User
   Agent on a PC, a standalone device which retreives 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",
   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

Masinter, Wing            Expires January 1999                 [Page 2]

Internet Draft           Extended Internet Fax            September 1998

   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
   these two operations are supplied by two different standards-track
   documents:  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 the delivery and processing confirmation
   section of this memo.

2.1.  Sender Requirements

   A delivery failure message (in a non-standard format or in the format
   described by [RFC1894]) 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

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 using the method described
   in section 2 of [RFC2298].

   Because a recipient can always silently ignore a request
   for an MDN [section 2.1 of RFC2298]:
     *  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
        always responded to MDNs 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 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

Masinter, Wing            Expires January 1999                 [Page 3]

Internet Draft           Extended Internet Fax            September 1998

   Disposition-Notification-To field).

2.2.   Recipient Requirements

   Recipients in compliance with this document SHOULD implement MDN
   [RFC2298], and SHOULD implement Offramp Gateway Extensions for DSN

   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, but a recipient MAY generate an unsolicited
   MDN (sent to the envelope-from (Return-Path:) address) to indicate
   processing failure following the rules in the above paragraph.

2.2.2.  Recipients using Mailbox Access Protocols

   A recipient using [POP3] or [IMAP4] to retrieve its mail is not
   allowed to generate a Delivery Status Notification message [RFC1894].

   The recipient MUST NOT use anything but the POP/IMAP username to map
   to a single destination.  For example, using any RFC822 field or
   information within the message body or MIME parts to make a decision
   about the destination is not permitted.

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

Masinter, Wing            Expires January 1999                 [Page 4]

Internet Draft           Extended Internet Fax            September 1998

   For the sender's infrastructure to provide conformance with
   this document, support for DSN [RFC1891] MUST be provided by the mail
   submission server [SUBMIT] 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 [RFC2305] only allows sending 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 SHOULD indicate which features and values from among
   those available in [FAX-SCHEMA] are supported using one of the
   mechanisms defined below.

   Three methods for the sender to acquire such knowledge are

     1.  Sender manual configuration
     2.  Capabilities in Directory
     3.  Capabilities returned in MDN or DSN

   In any implementation it possible for a locally-stored
   cache of capabilities to 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

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.

Masinter, Wing            Expires January 1999                 [Page 5]

Internet Draft           Extended Internet Fax            September 1998

   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.

   If the recipient implements [REPORTING-EXTENSIONS], 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).

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, it SHOULD be manually confirmed by a user
   before it is automatically used.

Masinter, Wing            Expires January 1999                 [Page 6]

Internet Draft           Extended Internet Fax            September 1998

4.2.  Forged MDNs or DSNs

   Forged DSNs or MDNs, as described in [RFC1892, RFC1894, RFC2298]
   can provide incorrect information to a sender.

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 [SUBMIT] 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 [RFC1893bis] status code of 5.6.--???-TBD-????--.  This status code
   may be returned in response to the end-of-mail-data indicator if the
   MTA supports [RFC2034], or after message reception by generating a
   delivery failure DSN ("bounce").

   Note:  Because DSN bounces are not requested by the sender and are
          not 'approved' by the receiver, DSNs can provide a more robust
          mechanism than performing this function in the MUA using MDNs.

   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:  Vivian Cancio, Richard Coles, David Crocker, Ned Freed,

Masinter, Wing            Expires January 1999                 [Page 7]

Internet Draft           Extended Internet Fax            September 1998

   Graham Klyne, MAEDA Toru, Geoff Marshall, Keith Moore, George Pajari,
   James Rafferty, Mike Ruhl, Richard Shockey, Brian Stafford, and
   Greg Vaudreuil.

7.  References

   [FAX-SCHEMA] L. McIntyre, G. Klyne, "Content feature schema for
   Internet fax", Internet Draft, Work in Progress,

   [GOALS] L. Masinter, "Terminology and Goals for Internet Fax",
   Internet Draft, Work in Progress, draft-ietf-fax-goals-XX.txt,

   [REPORT-EXTENSIONS] D. Wing, "Offramp Gateway Extensions to DSN and
   MDN", Internet Draft, Work in Progress,

   [RFC1891] K. Moore, "SMTP Service Extensions for Delivery Status
   Notifications", RFC 1891, January 1996.

   [RFC1893bis] G. Vaudreuil, "Enhanced Mail System Status Codes",
   Internet Draft, Work in Progress, (update to RFC 1893).

   [RFC1894] K. Moore, G. Vaudreuil, "An Extensible Message Format for
   Delivery Status Notifications", RFC 1894, January 1996.

   [RFC2034] N. Freed, "SMTP Service Extension for Returning Enhanced
   Error Codes", RFC 2034, 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.

   [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.

   [SUBMIT] R. Gellens, J. Klensin, "Message Submission", Internet
   Draft, Work in Progress, draft-gellens-submit-XX.txt.

8. Authors' Addresses

   Larry Masinter

Masinter, Wing            Expires January 1999                 [Page 8]

Internet Draft           Extended Internet Fax            September 1998

   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304  USA

   Fax:    +1 415 812 4333

   Dan Wing
   Cisco Systems, Inc.
   101 Cooper Street
   Santa Cruz, CA 95060  USA

   Phone:  +1 831 457 5200
   Fax:    +1 831 457 5208

9. 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

   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

Masinter, Wing            Expires January 1999                 [Page 9]