Applications Area                                         Larry Masinter
Internet Draft                                         Xerox Corporation
April 6, 1998                                                   Dan Wing
Expires September 1998                                     Cisco Systems


                       Operational Guidelines for
                              Fax over SMTP

                     draft-ietf-fax-operation-00.txt

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 ftp.is.co.za (Africa), ftp.nordu.net
   (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
   (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
   (US West Coast).

Copyright Notice

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

Abstract

   This document describes operational guidelines for devices and
   software which implement fax-over-SMTP [SERVICE].

   An device which implements [SERVICE] and this document will be able
   to exchange capabilities, confirm message receipt, perform immediate
   delivery, and determine the length of a call.

   Additionally, some guidelines are introduced to allow for new
   functions to be added without breaking older implementations.

1. Table of Contents

   1. Table of Contents
   2. Introduction
   2.1.  Requirements notation
   3. Message Headers
   3.1 From
   3.2 Sender
   3.3 To, Cc
   3.4 Date
   3.6 Subject
   2.  Addressing
   2.1 Special domain addresses for EIFax mail domains
   2.1.1 postmaster@domain
   2.1.2 abuse@domain, noc@domain, security@domain
   2.2 Source Address for Fax Onramps
   3. Cover Sheet Generation
   3.1.  Received: headers
   3.2.  Disclosing dial-access strings
   3.3.  Date
   4. Content-Types
   4.1 Image data: image/tiff
   4.2 multipart/mixed
   4.3  text/plain
   4.4  message/rfc822
   4.5  multipart/alternative
   4.6  multipart/signed, multipart/encrypted
   4.7  message/delivery-status, message/disposition-notification,
   4.8 Other Internet Media types
   5. Transport and Confirmation
   5.1 EIFax configurations
   5.2 Standard SMTP protocol elements
   5.2.1 MAIL FROM
   5.2.2  RCPT TO
   5.3 SMTP extensions
   5.3.1 Delivery notifications
   5.3.2 Binary MIME
   5.3.3 Capability request
   5.3.3 Immediate delivery
   5.3.4 Pipelining
   5.3.5 Size estimates
   5.3.6 Checkpoint/Restart
   5.3.7 Enhanced Error Codes
   5.4 Other transport mechanisms
   6. Operational Requirements and Limitations
   6.1  Onramp requirements
   6.2 Offramp requirements
   6.3 IFax sender limitations
   6.4 Limitations of Internet Mail
   6.4.1 number of recipients
   6.4.2 limitations on message size
   6.4.3 Limitations on quick delivery and confirmation
   7. Security Considerations
   8. Acknowledgments
   9. Copyright
   10. References
   11. Authors' Addresses
   A. Appendix A - Examples
   A.1  Full fax message
   A.2 Example disposition notification (with capabilities)
   A.3 Failure to display
   A.4 multipart/alternative

2. Introduction

   This document describes how implementations that are compliant with
   [SERVICE] can be implemented to also permit full functionality with
   EIFax implementations.

   Companion documents are:

     [FAXREQ]  "Requirements for Internet Fax", defines the basic
               terminology and goals for the Extended Internet Facsimile
               service of Fax over the Internet.

     [SERVICE] "A Simple Mode of Facsimile Using Internet Mail"

     [EIFAX]   "Extended Internet Facsimile using Internet Mail",
               capabilities exchange and delivery confirmation

2.1.  Requirements notation

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

   The intent in designing this specification is to require ("MUST")
   those items that are required to insure interoperability with
   devices that implement [EIFAX], and strongly recommend ("SHOULD")
   those items that are important for satisfying the user requirements
   for facsimile over the Internet.


3. Message Headers

   Internet Mail and MIME messages contain header fields.  These headers
   supply, information such as the sender, the list of recipients, the
   date of the message, the type of content, a list of mailers that
   have relayed the message, and other information.

 [[ Except for specialized gateway and mailing list cases,
   headers do not indicate delivery options for the transport of
   messages. ]]

   Internet mailing list software and mail redirection systems might
   modify, and will often add to the headers of messages that pass
   through them; for this reason, EIFax systems MUST be able to accept
   and (at a minimum) ignore headers that are not defined here.

   Header information should be preserved in some manner to allow
   debugging and determining a where a message originated from.  See
   section 4 for details.

3.1 From

   In Internet mail, the From header indicates the originator's (fully
   qualified) email address.  The From address is likely to be used for
   replies by email users. All EIFax mail MUST be identified with a From
   field which indicates the source of the message.

   For the benefit of text mail users, the From field generated by an
   onramp SHOULD include some text identification of the fact that the
   user is a fax service, e.g.,

      From: Fax'R'Us Service <fax=+16508124333@fax.xerox.com>

3.2 Sender

   In Internet mail, the Sender header contains the actual address of
   the originator if the message is sent by an agent on behalf of the
   author indicated in the From: field.

3.3 To, Cc

   In Internet mail, the To and CC headers contain the recipient's
   fully-qualified domain address.

     Examples:

        To: fax=+12145551213@mycompany.com
        To: fax=+12145551213@mycompany.com, dwing@cisco.com

   Note that the "To" address may not be the same as the delivery
   address of the recipient(s); this might happen for messages that are
   forwarded, sent through aliases, processed by mailing lists or
   mail gateways, or blind carbon copied.

3.4 Date

   In Internet mail, the Date header contains the date, time, and time
   zone in which the message was sent by the originator.  An EIFax
   sender system MUST include the Date header.

   If an EIFax sender cannot provide a Date header (because it lacks a
   clock and isn't running NTP [RFC1305] or SNTP [RFC2030]), the Date
   header can be generated using [SUBMIT].

3.6 Subject

   In Internet mail, the Subject field is often provided as an
   indication of the content of the message.

   Fax onramps and IFax senders SHOULD insert a useful subject header,
   for the benefit of text-capable recipients.

   Fax offramps and IFax recipients MAY include a printed representation
   of the subject line in the generated cover sheet of a message.


2.  Addressing

   In addition to the requirements in [SERVICE], the following
   additional requirements for addressing are included.

2.1 Special domain addresses for EIFax mail domains

   Several special email addresses are required or recommended for
   Internet mail domains [RFC2142].  This section points out the
   requirements for supporting special email addresses and the
   application to EIFax.

   An EIFax sender supplies a return address or an origin address for
   messages it sends.  For example, an EIFax onramp might supply a
   "From" address of "fax=+nnnnnnn@domain".  If "domain" is supported
   entirely by the same EIFax service ("offramp"), there are
   additionaly requirements for supporting special email addresses in
   EIFax devices:

       address                  requirement

      postmaster                   MUST
      abuse, noc, security         SHOULD
      non-mail-user                SHOULD (if appropriate)

   These are explained below.

   "Support" for such special addresses will vary depending on the
   physical implementation of the EIFax device.  Support means that
   mail sent to the address isn't lost and is handled appropriately,
   which usually means making the message, in its entirety, available
   to a human recipient by printing the message on the fax machine's
   printer, forwarding it to a human's mailbox, or dialing a local
   fax machine to print the message.

2.1.1 postmaster@domain

   [RFC822] requires special mailbox named "postmaster" MUST exist on
   all systems.  For a fax offramp,    This mailbox is particularly
   likely to receive text messages (non-MIME, and multipart/report).

2.1.2 abuse@domain, noc@domain, security@domain

   Fax offramp services which support an entire domain SHOULD support
   these addresses as defined in [RFC2142].

2.2 Source Address for Fax Onramps

   An EIFax sender MUST supply a valid MAIL FROM address for errors, and
   that address MUST be able to process non-MIME messages and the MIME
   types text/plain and multipart/report.

   Fax onramps that serve multiple users or locations MUST synthesize a
   valid source address, to allow the recipient of a fax to identify the
   sender and possibly to reply.  If generating a valid "From" address
   based on the fax sender is impossible (caller-ID unavailable), the
   mailing address of the administrator or service provider MAY be used.

3. Cover Sheet Generation

   Some of the message headers, such as From, To, CC, Subject, and Data,
   is intended for presentation to the user.  Other headers, such as
   Received, Content-Type, and Return-Path, are not normally presented
   to the user and are only useful during troubleshooting or to track
   abuse.

   It can often be impossible to determine if a cover page is already
   included in the message body, so such cover page generation MAY be in
   addition to any cover page included in the document body.

   Fax offramps SHOULD use the contents of the user-presentation
   headers (such as From, Subject, To, CC, possibly others) and the RCPT
   TO (if available) to generate a cover page.

   A From: address that includes a telephone number in standard form
   [FAXADDR] with a canonical telephone number might be able to use that
   telephone number as the "telphone number of the sender or of the
   sending fax machine", as is required by some legal authorities.

3.1.  Received: headers

   EIFax recipients MUST provide a mechanism to allow the display
   of mail headers, including "Received:" header fields, as a way
   of diagnosing misdirected mail or tracing the source of unwanted fax
   messages.  Such display need not occur on the cover page, but
   should be available in some manner to a system administrator.

   It can be problematic for an offramp to include the Received: headers
   on the cover page.  In an interactive Internet mail environment, it
   is common for the Mail User Agent to hide all but the 'normal'
   headers, but to offer the ability to display the rest of the mail
   headers when requested.However, for an offramp or IFax device, once
   the message has been printed or faxed, it is gone, and the value of
   these headers for tracking is lost. It is unlikely that users will
   find configuring options convenient.

3.2.  Disclosing dial-access strings

   Including the RCPT TO, and possible the To: header, on the cover page
   can cause unintentional disclosure of long-distance dial access
   strings.  To prevent such disclosure, the cover page should only
   contain telephone numbers that conform to [FAXADDR].

3.3.  Date

   Note that, for a message that is stored and forwarded through one or
   more Internet mail transfer agents, the time the message was sent by
   the message will be different than the time the message is received.
   An EIFax offramp SHOULD identify the time of fax transmission over
   the PSTN in addition to, or instead of, the time of origin, in order
   to satisfy the legal requirement of identifying the date of
   transmission.


4. Content-Types

   MIME defines a general mechanism by which many kinds of message
   bodies may be sent over Internet mail.  The content type of a message
   body is indicated by the "Content-Type" header.  A content type label
   consists of a top level type ("image", "text", "application", etc.),
   a subtype, and an optional set of parameters and parameter values.
   New content-types may be registered.  Some content types within
   "message", "multipart" have a special role as structural designators.

   [SERVICE] defines a minimum level of conformance for Facsimile using
   Internet Mail.  This section lays out the message content types that
   are required or optional for EIFax over and above those required by
   [SERVICE], and describes the contexts in which these formats might be
   sent. The following summary is explained in subsequent sections.

     Type                   Sender                 Recipient
  image/tiff (minimum F)   SHOULD                   MUST
  image/tiff (beyond min)  SHOULD NOT               MAY
  multipart/mixed          MAY                      MUST
  multipart/alternative    MAY                      MUST
  message/rfc822           SHOULD NOT               SHOULD
  multipart/signed         MAY                      MUST accept,
                                                     SHOULD verify
  multipart/encrypted      MAY                      MAY
  message/delivery-status  SHOULD (when requested)  MUST (return address)
  message/disposition-notification
                           SHOULD (as appropriate)  MUST (return address)
  multipart/report         MAY (when appropriate)   MUST (return address)
  text/plain               SHOULD NOT               MUST (return address)
  any other file type      MAY (when appropriate)   MAY

   These requirements apply to all EIFax senders and recipients.  Note
   that some 'recipient' requirements apply to the 'return address'
   supplied by an EIFax sender rather than to all EIFax recipients.

4.1 Image data: image/tiff

   [SERVICE] requires that all senders accept the minimum subset of the
   "F" profile of TIFF for Fax [TIFF].  In addition, EIFax recipients
   SHOULD support the entire range of the "F" profile, and MAY accept
   other profiles.

   EIFax senders MUST use the minimum subset of the "F" profile when the
   capabilities of the recipient are unknown.

   EIFax senders MAY use other applications of [TIFF] if the
   capabilities of the recipient are known to include the handling of
   those applications.  See [EIFAX] for a description of how
   capabilities of the remote system can be learned.

4.2 multipart/mixed

   EIFax recipients MUST accept multiple message bodies to be
   concatenated together on display using multipart/mixed. EIFax senders
   MAY send such messages, as needed; it is allowable for individual
   pages to be sent as separate image/tiff images within
   multipart/mixed, although such use is not recommended.

   Note that unregonized multipart messages, such as multipart/signed,
   are interpreted as if they were multipart/mixed.

4.3  text/plain

   EIFax senders SHOULD NOT send plain text messages. That is, EIFax is
   not intended as a replacement for text messaging.  However, in the
   normal email environment, the prevalence of
   "text/plain;charset=US-ASCII" as the baseline format for Internet
   mail means that recipients that reject simple text messages would not
   be able to properly function.

   An EIFax recipient MUST accept plain text messages. It might convert
   the text into the proper format for forwarding (via a text-to-fax
   converter) or might operate by forward text messages on to another
   recipient that is more capable, but in all cases, text messages MUST
   be processed.

4.4  message/rfc822

   In Internet mail, a message is often stored, saved, and later forward
   to another email address. To support the ability to forward EIFax
   messages to other EIFax recipients, EIFax recipients MUST accept
   message/rfc822 encapsulated messages, and process them appropriately.

4.5  multipart/alternative

   In Internet mail, the "multipart/alternative" [RFC2046] construct
   allows for a sender to send a document in more than one format,
   within the same message, in the case where the capabilities of the
   recipient are not known and cannot be discovered. It is inefficient,
   since the content is repeated multiple times, and is used sparingly.

   In order to allow for the upgrade of facsimile messages to different
   capabilities EIFax recipients MUST accept messages using
   "multipart/alternative",as long as _one_ of the parts is acceptable,
   and choose (from the enclosed content) one of the alternatives to
   display or print.  While [RFC 2046] specifies that systems SHOULD
   chose the "best" type, based on the local environment and references,
   limited memory EIFax recipients MAY handle "multipart/alternative" by
   interpreting the _first_ acceptable type.

   An EIFax sender MAY send a "multipart/alternative" that contains
   *any* media types intermixed, as long as one of the parts is
   allowable; the alternatives SHOULD appear in an order of _increasing_
   faithfulness to the original content, as specified in [RFC2046].

4.6  multipart/signed, multipart/encrypted

   In order to promote the use of authentication technology, EIFax
   recipients MUST accept signed messages, and SHOULD attempt to verify
   the signature, and indicate success or failure.

   In order to promote the use of message security, EIFax recipients
   SHOULD accept encrypted messages.  Senders SHOULD be capable of
   sending encrypted messages to those recipients for which encryption
   is available.

   See section 9 (Security)

4.7  message/delivery-status, message/disposition-notification,
     multipart/report

   The details of EIFax confirmation are contained in section 7
   (Confirmation). Note that section 8 (Capabilities) defines an
   extension to message/disposition-notifications that allows recording
   of the recipient's capabilities. Any EIFax sender (or, more
   accurately, the return address specified by an EIFax sender) MUST be
   able to accept and automatically process a "multipart/report"
   message.

4.8 Other Internet Media types

   EIFax recipients MAY also conditionally accept messages in other
   formats. That is, there is no restriction that EIFax only be used for
   TIFF or other MIME types.  An EIFax sender SHOULD NOT send media that
   it does not have some reliable indication that the recipient can
   accept, but, using capabilities statements, it is possible for an
   EIFax recipient (Internet mail user, IFax device, offramp) to accept
   other media types, including "application/postscript",
   "application/pdf", "image/jpeg", or (if properly labeled) media with
   proprietary or vendor-specific information, using any registered type
   [RFC2046].


5. Transport and Confirmation

   Data transfer in EIFax is achieved using any acceptable Internet mail
   transfer mechanism.  The typical choice is SMTP, especially between
   organizations across the Internet.

   Section 6.1 discusses the various configurations for EIFax senders
   and recipients. Section 6.2 discusses the use of standard SMTP for
   Fax. Section 6.3 describes some ESMTP extensions that are recommended
   for direct SMTP participants, and section 6.4 describes other
   transport protocols that may be used for fax messaging.

5.1 EIFax configurations

   EIFax senders (of all types) MAY use simple SMTP with no extensions,
   deliverying store and forward messages directly to a 'mail drop'.
   The protocol in [SUBMIT] is an alternative protocol.  In addition,
   EIFax senders of all types MAY directly connect to the final Mail
   Transfer Agent of the recipient, looking up the recipient's MX DNS
   entry [RFC974].

   EIFax recipients (of all types) MAY be simple Internet mail user
   agents. The using protocols such as POP [RFC1939] or IMAP [RFC2060].
   Alternatively, an EIFax offramp or IFax device with a permanent
   Internet connection MAY operate as a SMTP server.

   For delivery to classic fax devices via an offramp (gateway),
   Internet mail delivery refers to transport to the EIFax offramp,
   rather than transport to the final, classic fax device.

   The special case of "direct connection" provides additional
   opportunities for optimization: the phrase "direct connection" will
   be used to refer to the case where

     (a) the EIFax sender implements full mail routing [RFC 874]

     (b) the recipient is an EIFax offramp or IFax device which
         implements SMTP

     (c) a direct connection between the sender and recipient is
         available (e.g., both on the same local Intranet or both on the
         public Internet)

5.2 Standard SMTP protocol elements

[[ I think SERVICE covered this sufficiently?

   The elements of SMTP are defined in RFC 821. This section points out
   appropriate use of these elements in EIFax.

5.2.1 MAIL FROM

   The MAIL FROM address indicates where errors (bounces) are to be
   sent.  It may not have a relationship to the "From:" or "Sender:"
   mail headers.

The MAIL FROM address is converted to a Return-Path header by the
final delivering SMTP server.  If the Return-Path is present, it
contains the address from the MAIL FROM parameter of the SMTP exchange
to which error messages MUST be sent (see [RFC1891] for additional
details).

5.2.2  RCPT TO

This is the actual recipient.  Note that this doesn't necessarily
have any relationship to the "To:" or "CC:" message headers.

]]

5.3 SMTP extensions

   EIFax makes no mandatory requirements for additions or enhancements
   to the standard Internet Mail environment.

   However, there are some enhancements to SMTP delivery of mail which
   provide additional desirable functionality. These enhancements are
   available as SMTP extensions, as defined in [RFC1869].

     SMTP client
     -----------
       Extension                            recommendation
       ---------------                      -----------
       [RFC1891] Delivery notifications     SHOULD
       [RFC1830] Binary MIME                MAY
       [CAPS] Capabilities request/response SHOULD
       [SESSION] Immediate delivery         SHOULD
       [RFC2197] Pipelining                 MAY
       [RFC1870] Size estimates             MAY
       [RFC1845] Checkpoint/Restart         MAY
       [RFC2034] Enhanced Error Codes       MAY

     SMTP server
     -----------
       Extension                            recommendation
       ---------------                      -----------
       [RFC1891] Delivery notifications     SHOULD
       [RFC1830] Binary MIME                MAY
       [CAPS] Capabilities request/response SHOULD
       [SESSION] Immediate delivery         MAY
       [RFC2197] Pipelining                 SHOULD
       [RFC1870] Size estimates             MAY
       [RFC1845] Checkpoint/Restart         MAY
       [RFC2034] Enhanced Error Codes       SHOULD


   Each of these is explained below.

5.3.1 Delivery notifications

   This is a standard part of the Internet Mail environment [RFC1891].
   The requirements for delivery status notifications in EIFax are
   discussed in [EIFAX].

5.3.2 Binary MIME

   This is an experimental protocol for Internet Mail.[RFC1830] Its use
   would eliminate the overhead otherwise entailed by the required
   base64 encoding of the binary image data.

   The application of Binary MIME is RECOMMENDED for the "direct
   connect" case, but support of direct connect itself is OPTIONAL.

5.3.3 Capability request

   This extension is RECOMMENDED only for the "direct connect" case.

   The capability extensions in [CAPS] allow a SMTP server to tell the
   sending SMTP implementation about the format capabilities of various
   recipients. This allows efficient transfer of appropriate data. It is
   only useful when the ESMTP server is able to access direct and
   up-to-date information about the recipient; its use is recommended in
   that situation.  If senders are able to generate documents in
   multiple formats, senders SHOULD implement this option.

5.3.3 Immediate delivery

   This extension is recommended for the "direct connect" case.

   The SESSION extension allows for immediate delivery end-to-end when
   there are live connections between sender and recipient.  It is most
   appropriate when sender and recipient are both connected directly to
   the Internet. Based on user preferences (for immediate or delayed
   delivery, for example) EIFax senders MAY attempt to perform immediate
   delivery, and EIFax recipients SHOULD support immediate delivery.

5.3.4 Pipelining

   This extension is RECOMMENDED for any SMTP sender or recipient.

   The pipelining feature reduces the total number of necessary round
   trip delays in an SMTP transaction.  This is especially useful in
   high-latency networks.  Senders SHOULD use pipelining if the
   recipient supports it, and recipients SHOULD support pipelining.

5.3.5 Size estimates

   The use of the [RFC1870] extension is recommended as a way of
   avoiding sending a message that is too large through a mail gateway.
   The conventional means of splitting large messages into smaller
   message/partial components seems to be not as useful for Internet
   Fax.  The sending application might instead split a single fax into
   multiple messages.

   An onramp, which is unable to determine how many pages are in a fax,
   is unable to utilize SIZE.

5.3.6 Checkpoint/Restart

   The checkpoint/restart features of ESMTP would help onramps keep
   connections alive. The utility of this feature for fax
   onramp/offramps is uncertain.

5.3.7 Enhanced Error Codes

   This extension is recommended for any SMTP participant.  This allows
   more useful status information to be returned to the sender.

5.4 Other transport mechanisms

   The use of client/server desktop mailbox protocols like IMAP or POP
   to retrieve EIFax messages from a message store is possible without
   any special modifications to this specification.  Email clients (and
   web browsers) typically have a table for mapping from MIME type to
   displaying application.  The image/tiff and content can be configured
   so that they invoke the correct viewer for rendering.

6. Operational Requirements and Limitations

   This section describes operational requirements for several elements
   and agents, and the limitations expected for such devices.

6.1  Onramp requirements

   A fax onramp provides a service of accepting a PSTN fax telephone
   call, and forwarding the fax via the (E)SMTP protocol, as outlined
   herein. In order to meet the timeouts of PSTN fax, it is necessary
   either that the onramp be able to store and guarantee complete
   delivery of the message at a later time, or else that the next hop
   SMTP server provide a positive response of message receipt within the
   timeout interval.

   In practice, this requirement means that the onramp's next hop must
   respond to the end-of-mail data (which is "." if using normal DATA,
   or BDAT LAST if using BDAT from [CHUNK]) within the nominal T.30
   timeouts [T.30], believed to be 30 seconds.

6.2 Offramp requirements

   <<this section should summarize requirements for offramps, it is
   incomplete>>

   Fax offramps SHOULD support [RFC1891], [MDN], and [FAXDSN]. MAY
   generate cover pages based on message headers. Fax offramps MAY be
   capable of accepting higher resolution images and converting them
   into representations that can be accepted by the fax terminals that
   they are forwarding the message to. Fax offramps MAY support other
   message formats, such as "application/postscript".

   [[also see section 6.3, smtp service extensions]]

6.3 IFax sender limitations

   Internet fax machines usually act as an integrated Message User
   Agent, often only collecting telephone numbers from the user, but
   sometimes having a full alphanumeric keypad allowing entering
   usernames (looked up in a database) or a normal email address;

   Internet fax machines are not expected to contain a disk drive or
   sufficient memory to buffer many pages of document images, e.g., to
   hold the document until confirmation is available.

   IFax machines must either be capable of accepting text/plain
   messages, or forwarding them to a user's system which *is* capable of
   accepting such messages.

6.4 Limitations of Internet Mail

   The following are limitations of Internet Mail agents that were
   considered in designing this protocol.

6.4.1 number of recipients

   Some Internet Mail implementations may limit the number of recipients
   allowed for a single message; a redistribution agent for Internet Fax
   may not be able to queue a large number of outgoing fax messages,
   with the limit even possibly being a single recipient.  However,
   ESMTP currently does not provide a mechanism for indicating the
   number of supported recipients.

   If an SMTP server has reached its limit for maximum number of
   recipients, it should respond with a 4xx reply code which allows the
   SMTP client to retry sending later.

6.4.2 limitations on message size

   Some Internet Mail transfer agents may have a limit on the maximum
   message length, and may be unable to transfer long documents.  This
   protocol does not limit the maximum message length.  Implementers
   should understand that some mailers will be unable to accept
   excessively long messages.

6.4.3 Limitations on quick delivery and confirmation

   In many configurations of Internet Mail, the SMTP server does not
   handle final delivery to the recipient, but delivers the message to a
   message repository.

   SMTP delivery is usually not immediate, and confirmation of delivery
   (if any) is also not immediate.  SMTP cannot, in general, guarantee
   to provide confirmation or non-confirmation of delivery. (Extensions
   to SMTP may allow immediate delivery.)

   In this case, "delivery" does not indicate that the message has been
   printed, but only that it is in a repository under the control of the
   recipient. If the ultimate EIFax recipient then subsequently
   retrieves and prints the message, the sender's expectation of
   "confirmation" may not correspond.

   There is no mechanism to regenerate lost confirmation messages, even
   when such facilities are deployed.

   Full functionality, such as reliable error messages and binary
   transport, will require careful selection of gateways (e.g., via MX
   records) to be used as forwarding agents.  Nothing in this document
   precludes use of a general purpose MIME email packages (such as
   Eudora, Navigator, Internet Explorer) to read and compose EIFax
   messages.

7. Security Considerations

   The requirements for security in Internet Fax are enumerated in
   [FAXREQ].

   Security threats and their countermeasures are described in
   [SERVICE].

   Additional security threats created by new features are described in
   [EIFAX].

8. Acknowledgments

   Many thanks to Graham Klyne and Vivian Cancio, who provided a number
   of careful reviews of this document, and to Ken Camarro, Robert
   Rosenberg, George Pajari, Mike Lake, Glen Parsons, Paul Van Schagen
   and others who supplied many valuable comments. Many of the concepts
   here were originated in the work of other authors, including Mike
   Lake, Dave Crocker, Kiyoshi Toyoda, Hiroyuki Ohno, Jun Murai, and the
   VPIM authors, including G. Vaudreuil and G. Parsons.

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

10. References

   [CAPS] D. Wing, N. Joffe, "SMTP Service Extension for Capabilities
   Exchange", Internet Draft, Work in Progress,
   draft-ietf-fax-smtp-capabilities-??.txt.

   [EIFAX] L. Masinter, "Extended Internet Facsimile using Internet
   Mail", Internet Draft, Work in Progress, draft-ietf-fax-fpim-??.txt

   [FAXADDR] C. Allocchio, "PSTN and fax address format in e-mail
   services", Internet Draft, Work in Progress,
   draft-ietf-fax-addressing-??.txt.

   [FAXDSN] D. Wing, "Extensions to Delivery Status Notifications for
   Fax", Internet Draft, Work in Progress,
   draft-ietf-fax-dsn-extensions-??.txt

   [FAXREQ] L. Masinter, "Requirements for Internet Fax", Internet
   Draft, Work in Progress, draft-ietf-fax-requirements-??.txt.

   [CONSCEN] E. Hardie, "Scenarios for the Delivery of Negotiated
   Content", November 1997, <draft-ietf-http-negotiate-scenario-02.txt>

   [FEATREG] K. Holtman, A. Mutz, "Feature Tag Registration Procedures",
   July 1997, <draft-ietf-http-feature-reg-02.txt>.

   [FEATSCEN] K. Holtman, A. Mutz, "Feature Tag Scenarios", July 1997,
   <draft-ietf-http-feature-scenarios-01.txt>.

   [FEATMED] L. Masinter, "Features for Media Display", November 1997,
   <draft-masinter-media-features-00.txt>.

   [ITUDC] D. Crocker, "Procedures for the Transfer of Facsimile Data
   via Internet Mail", Internet Draft, Work in Progress,
   draft-ietf-fax-itudc-??.txt.

   [MDN] R. Fajman, "An Extensible Message Format for Message
   Disposition Notifications", Internet Draft,
   draft-ietf-receipt-mdn-??.txt.  <<approved for Proposed Standard>>

   [RFC821] J. Postel, "Simple Mail Transfer Protocol", STD 10, RFC 821,
   August 1982.

   [RFC822] D. Crocker, "Standard for the Format of ARPA Internet Text
   Messages", STD 11, RFC 822, August 1982.

   [RFC974] C. Partridge. "Mail routing and the domain system", STD ??,
   RFC 822, January 1986.

   [RFC1123] R. Braden, "Requirements for Internet hosts - application
   and support", RFC 1123, October 1989.

   [RFC1305] D. Mills, "Network Time Protocol (Version 3):
   Specification, Implementation and Analysis", RFC 1305, March 1992.

   [RFC1830] G. Vaudreuil, "SMTP Service Extensions for Transmission of
   Large and Binary MIME Messages", RFC 1830, October 1995.

   [RFC1845] D. Crocker, N. Freed, A. Cargille, "SMTP Service Extension
   for Checkpoint/Restart", RFC 1845, September 1995.

   [RFC2197] N. Freed, A. Cargille, "SMTP Service Extension for Command
   Pipelining", RFC 2197.

   [RFC1869] J. Klensin, N. Freed, M. Rose, E. Stefferud, D. Crocker,
   "SMTP Service Extensions", RFC 1869, November 1995.

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

   [RFC1892] G. Vaudreuil, "The Multipart/Report Content Type for the
   Reporting of Mail System Administrative Messages", RFC 1892, January
   1996.

   [RFC1893] G. Vaudreuil, "Enhanced Mail System Status Codes", RFC
   1893, January 1996.

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

   [RFC1870] J. Klensin, N. Freed, K. Moore, "SMTP Service Extensions
   for Message Size Declaration", RFC 1870, November 1995.

   [RFC1911] G. Vaudreuil, "Voice Profile for Internet Mail", RFC 1911,
   Feb 1996.

   [RFC1939] J. Myers, M. Rose, "Post Office Protocol - Version 3", STD
   53, RFC 1939, May 1996.

   [RFC2030] D. Mills, "Simple Network Time Protocol (SNTP) Version 4
   for IPv4, IPv6 and OSI", RFC 2030, October 1996.

   [RFC2034] N. Freed, "SMTP Service Extension for Returning Enhanced
   Error Codes", RFC 2034, October 1996.

   [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail
   Extensions (MIME) Part One:  Format of Internet Message Bodies", RFC
   2045, November 1996.

   [RFC2046] N. Freed, N. Borenstein, "Multipurpose Internet Mail
   Extensions (MIME) Part Two:  Media Types", RFC 2046, November 1996.

   [RFC2048] N. Freed, J. Klensin, J. Postel, "Multipurpose Internet
   Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048,
   November 1996.

   [RFC2049] N. Freed, N. Borenstein, "Multipurpose Internet Mail
   Extensions (MIME) Part Five:  Conformance Criteria and Examples", RFC
   2049, November 1996.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, March 1997.

   [RFC2142] D. Crocker, "Mailbox Names for Common Services, Roles and
   Functions", RFC 2142, May 1997.

   [RFC2184] N. Freed, K. Moore, "MIME Parameter Value and Encoded Word
   Extensions:  Character Sets, Languages, and Continuations", RFC 2184,
   August 1997.

   [SERVICE] K.Toyoda, H. Ohno, J. Murai, D. Wing, "A Simple Mode of
   Facsimile Using Internet Mail", Internet Draft, Work in Progress,
   draft-ietf-fax-service-01a.txt, December 1997.

   [SESSION] N. Joffe, D. Wing, L. Masinter, "SMTP Service Extension for
   Immediate Delivery", Internet Draft, Work in Progress,
   draft-ietf-fax-smtp-session-??.txt.

   [SUBMIT] R. Gellens, H. Alvestrand, "Message Submission and Relay",
   Internet Draft, Work in Progress, draft-gellens-submit-??.txt.

   [TIFF] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J.
   Rafferty, "File Format for Internet Fax",
   <draft-ietf-fax-tiffplus-03.txt>.

   [TIFF-ADOBE] Tag Image File Format, Revision 6.0, Adobe Developers
   Association, June 3, 1992,
   ftp://ftp.adobe.com/pub/adobe/devrelations/
   devtechnotes/pdffiles/tiff6.pdf, "The TIFF 6.0 specification dated
   June 3, 1992 specification, Copyright (c) 1986-1988, 1992 Adobe
   Systems Incorporated. All Rights Reserved."

   [TIFF-F] G. Parsons, J. Rafferty, "Tag Image File Format (TIFF) -
   Application F", Internet Draft, Work in Progress,
   <draft-ietf-fax-tiff-05.txt>.

   [VPIM] G. Vaudreuil, G. Parsons, "Voice Profile for Internet Mail -
   version 2", <draft-ema-vpim-06.txt>. (Updates [RFC 1911]).

11. Authors' Addresses

   Larry Masinter
   Xerox Palo Alto Research Center
   3333 Coyote Hill Road
   Palo Alto, CA 94304  USA
   Fax:    +1 415 812 4333
   EMail:  masinter@parc.xerox.com


   Dan Wing
   Cisco Systems, Inc.
   101 Cooper Street
   Santa Cruz, CA 95060  USA
   Phone: +1 408 457 5200
   Fax:   +1 408 457 5208
   EMail: dwing@cisco.com

A. Appendix A - Examples

A.1  Full fax message

   The following message is a full-featured, all-options-enabled message
   addressed to two recipients.

   << not supplied yet >>

A.2 Example disposition notification (with capabilities)

        Date: Wed, 20 Dec 1997 00:19:00 (EDT) -0400
        From: Fax +1 650 812 4333 <fax=+1-650-812-4333@offramp.xerox.com>
        Message-Id: <199509200019.12345@offramp.xerox.com>
        Subject: Disposition notification
        To: Fax +1 555 555 1212 <fax=+1-555-555-1212@spammer.com>
        MIME-Version: 1.0
        Content-Type: multipart/report; report-type=disposition-notification;
              boundary="RAA14128.773615765"

        --RAA14128.773615765

        The message sent on 19 Dec 1997 11:55:00 (EDT) -0400 to
        <fax=+1-650-812-4333@offramp.xerox.com> was successfully forward
        to the telephone-based fax number <+1-650-812-4333>.

        --RAA14128.773615765
        content-type: message/disposition-notification

        Reporting-UA: offramp.xerox.com; Offramp Megabucks Software
        Original-Recipient: rfc822;fax=+1-650-812-4333@offramp.xerox.com
        Final-Recipient: fax;+1-650-812-4333
        Original-Message-ID: <199509192301.12345@spammer.com>
        Disposition: automatic-action/MDN-sent-automatically; forwarded
        Capabilities: tiff=M

        --RAA14128.773615765

A.3 Failure to display

        Date: Wed, 20 Dec 1997 00:19:00 (EDT) -0400
        From: Fax +1 650 812 4333 <fax=+1-650-812-4333@offramp.xerox.com>
        Message-Id: <199509200019.12345@offramp.xerox.com>
        Subject: Fax failure
        To: Fax +1 555 555 1212 <fax=+1-555-555-1212@spammer.com>
        MIME-Version: 1.0
        Content-Type: multipart/report; report-type=disposition-notification;
              boundary="RAA14128.773615767"

        --RAA14128.773615767

        The message sent on 19 Dec 1997 11:50:00 (EDT) -0400 to
        <fax=+1-650-812-4333@offramp.xerox.com> failed to forward
        to the telephone-based fax number <+1-650-812-4333>.

        --RAA14128.773615765
        content-type: message/disposition-notification

        Reporting-UA: offramp.xerox.com; Offramp Megabucks Software
        Original-Recipient: rfc822;fax=+1-650-812-4333@offramp.xerox.com
        Final-Recipient: fax;+1-650-812-4333
        Original-Message-ID: <199509192301.12347@spammer.com>
        Disposition: automatic-action/MDN-sent-automatically; processed, error
        capabilities="tiff=f,tiff=s,itut=0x1AEEF"

        --RAA14128.773615765


A.4 multipart/alternative

A.5 ...