One document matched: draft-ietf-fax-operation-00.txt
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 ...
| PAFTECH AB 2003-2026 | 2026-04-23 11:21:22 |