Network Working Group Neil Joffe
INTERNET-DRAFT Dan Wing
July 11, 1997 Charles Kline
Expires December 1997 Cisco Systems, Inc.
Capabilities Exchange and Immediate Delivery over ESMTP
draft-ietf-fax-transport-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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow
Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).
Overview
This document describes extensions to SMTP to allow capabilities
exchange and immediate (session mode) delivery of messages. These
extensions are intended primarily for fax, but may have other uses.
Internet Fax Working Group
This document is a product of the IETF Internet Fax Working Group. All
comments on this document should be forwarded to the email distribution
list at <ietf-fax@imc.org>.
1. Abstract
This memo defines two SMTP service extensions:
1. "CAPABILITIES", which causes the ESMTP server to respond with
capabilities of the recipient or of the ESMTP server itself and
Joffe, Wing, Kline Expires December 1997 [Page 1]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
2. "SESSION", which provides a mechanism for immediate delivery
(where the client waits for the server to deliver the message
instead of storing and forwarding it).
2. Introduction
ESMTP [SMTP-EXT] is a reliable Internet mail transport protocol that has
no strict bandwidth or latency sensitive requirements. Historically,
SMTP has been used for store and forward (s&f) delivery of messages.
This draft further expands on store and forward delivery by allowing the
ESMTP server to advertise capabilities so that a compliant client will
send a format that the recipient can decode. Recipients may be mail
spoolers, dial-up clients, legacy fax machines and Internet enabled fax
machines. Additionally, this draft defines a new transport mode for
SMTP delivery known as SESSION mode. When this mode is used, the server
delivers the message before the client disconnects from it. The server
has an option to fall back automatically to s&f delivery if session mode
fails.
This draft defines a transport for different media which will allow a
universal inbox and single user interface. At the same time the "user
experience" with legacy technology, such as fax, can be maintained .
If we examine fax transmissions on the PSTN, the following
characteristics are important:
a. immediate transmission of the message
b. image format is negotiated between sender and receiver
c. immediate transmission confirmation available to sender
The CAPABILITIES extension provides (b) over store and forward email;
and CAPABILITIES combined with SESSION provides (a), (b), and (c).
2.1. CAPABILITIES Extension
The CAPABILITIES extension permits an ESMTP client to easily obtain a
recipient's capabilities (to prevent sending data which the recipient
will be unable to decode or otherwise use).
The CAPS keyword in RCPT TO causes the server to advertise recipient
capabilities. Capabilities can be:
a. those of the actual recipient (if known through some database,
LDAP query, or other implementation-specific mechanism)
b. those of the ESMTP server if it is willing to accept and
translate to the actual capabilities of the recipient, once those
Joffe, Wing, Kline Expires December 1997 [Page 2]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
capabilities are known.
2.2. SESSION Extension
The SESSION extension allows fax-like behavior over ESMTP, causing
immediate delivery (without store and forward) to the destination
address.
Session mode over ESMTP is used when sending from legacy fax to legacy
fax or when a user instructs their MUA that immediate delivery is
desirable. This provides the same "user experience" as a legacy fax or
[BFT, BFT-FAQ] - specifically immediate transmission and reception of
the message and immediate confirmation. With pure session delivery, no
store-and-forward is performed.
3. Framework for capabilities extension
The following service extension is defined for capabilities exchange.
(1) The name of the capabilities extension is "CAPABILITIES";
(2) the EHLO keyword value associated with the capabilities extension
is "CAPABILITIES";
(3) no parameters are allowed with this extension;
(4) no new SMTP verbs are associated with this extension;
(5) the optional parameter "CAPS" is added to the RCPT TO command,
which instructs the ESMTP server to advertise the capabilities of
the recipient or of the ESMTP server itself (see section 4);
(6) the maximum length of RCPT TO is increased by 5 characters.
4. RCPT TO:<forward-path> CAPS
A RCPT TO command issued by a client may contain the optional esmtp-
keyword "CAPS" to indicate that the ESMTP client wishes to receive
recipient capabilities information in the RCPT TO response from the
ESMTP server.
The server should be aware of the nature of the recipient via some
implementation-specific method (LDAP or other directory query, vCard,
dialing the destination system directly, or some other method). The
server may advertise its own capabilities if it is willing to convert to
Joffe, Wing, Kline Expires December 1997 [Page 3]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
the actual capabilities of the recipient (or the next SMTP server if
relaying a message via store-and-forward) when those capabilities are
known.
4.1. Responses to RCPT TO esmtp-keyword CAPS
The response to the esmtp-keyword CAPS on a RCPT TO command is a
multiline reply of the standard SMTP reply followed by recipient
capabilities in the format specified by [HTTP-HEAD] and [HTTP-ATTR].
"Accept-Encoding: " formats such as MH, MR, MMR, JBIG, JPEG will be
registered with IANA.
The ESMTP server only needs to indicate capabilities if the ESMTP server
is responding with a positive (2xx) reply. Non-positive replies don't
need to include capabilities and such capabilities are to be ignored by
the ESMTP client if they are present.
The response, in [ABNF] form is:
caps-response = "250" SP rcpt-response /
( "250-" SP rcpt-response CR LF
*( "250-" http-line / ttl-fax-caps CR LF )
"250" SP http-line / ttl-fax-caps CR LF )
where "rcpt-response" is the normal response issued by the ESMTP server
when it receives a valid forward-path. Note section 2.2.9 of
[PIPELINING] recommends that the response text indicate which command
the response matches.
As time to live and legacy fax characteristics are not described in
[HTTP-ATTR], the following are defined:
ttl-fax-caps = "Accept-Features:" SP ttl-caps ["," SP fax-caps ]
ttl-caps = "ttl=" ttl-seconds
ttl-seconds = *DIGIT
fax-caps = "csid=" csid ["," SP "nsf=" nsf]
csid = *CHAR
nsf = *CHAR
The purpose of <ttl> is to indicate how long the list of capabilties
should be considered an authoritative list of capabilities. The ttl is
decremented by the ESMTP server for the length of time since the data
was last refreshed. A ttl of 0 indicates the capabilities list is out-
Joffe, Wing, Kline Expires December 1997 [Page 4]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
of-date, should not be cached by any system receiving ttl=0, and that
newer capabilities are not obtainable at this time. The initial value
of ttl is implementation specific, and should be obtained from a data
source controlled by the recipient if possible.
The purpose of <legacy-caps> is to allow the ESMTP server to display
non-standard and/or unique attributes of the recipient. csid and nsf are
case insensitive.
4.2. ESMTP server unable to obtain capabilities
If the ESMTP server receives a request for recipient capabilities (via
the esmtp-keyword CAPS), but cannot determine the capabilities of the
recipient for some reason, the ESMTP server may reply with:
(1) ttl=0, or
(2) cached capabilities and ttl=0
This allows the ESMTP client to either:
(a) abort the transaction, or
(b) send the 'enhanced' data using client-cached recipient
capabilities for case (1); or using the recipient capabilities
returned by the ESMTP server for case (2) and include a baseline
TIFF-F as multipart/alternative; or
(c) send baseline TIFF-F.
4.3. Example capabilities exchange
S: 220 gw.cisco.com SMTP service ready
C: EHLO fax.symantec.com
S: 250-gw.cisco.com says hello
S: 250 CAPABILITIES
C: MAIL FROM:<+1-416-446-8022@fax.symantec.com>
S: 250 <+1-416-446-8022@fax.symantec.com> sender ok
C: RCPT TO:<+1-408-526-7544@gw.cisco.com> CAPS
S: 250-<+1-408-526-7544@gw.cisco.com> recipient ok
S: 250-Accept: audio/basic
S: 250-Accept: image/tiff;application=f, image/tiff;application=fx,
application/octet-stream
S: 250-Accept-Features: papersize=na-letter, papersize=iso-a4
S: 250-Accept-Features: pix-x=1728, res=204x196
S: 250-Accept-Encoding: MH, MR, MMR
Joffe, Wing, Kline Expires December 1997 [Page 5]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
S: 250 Accept-Features: csid=+1408-526-7544, ttl=500
C: DATA
5. Format of fax image data
The format of the data uses the MIME sub-type image/tiff for Application
F, described in [TIFF-F]. Other MIME types, such as [TIFF-FX] and [PDF]
may be used.
The fax image data does not contain T.30 commands, non-standard features
(NSFs), addressing, or capabilities information.
The ESMTP client is not permitted to send a file format exceeding the
capabilities returned with CAPS. If the ESMTP client exceeds the
capabilities that were returned in the CAPS response, the ESMTP server
should refuse the message via a 550 reply or use 550 5.6.1 [ENH-RET], if
supported.
The SMTP client is allowed to send a message without requesting
capabilities (this is what happens with email today). However, if the
SMTP client is sending a fax that exceeds baseline TIFF-F, and the SMTP
client determined the recipient is capable of receiving a fax format
that exceeds TIFF-F by a means other than a non-cached answer from a
recipient-controlled information source, the SMTP client must send
baseline TIFF-F as a multipart/alternative in addition to the enhanced
image. This ensures the recipient will always be able to decode the fax
image in the event of incorrect or out-of-date recipient capabilities
information.
For a faxing implementation, if the ESMTP client doesn't request
capabilities and exceeds the baseline TIFF-F without sending
multipart/alternative, the ESMTP server may refuse the message via a 5xx
reply.
The format of binary files over data networks will be the Content-Type
matching the application (when possible) or application/octet-stream
(when the application cannot be determined)..
6. Delivery Status Notification
To allow confirmation of store-and-forward fax, servers MUST implement
[DSN]. It is expected that users will want delivery notification
similar to today's fax machines, which is notification of failure,
success, and delayed delivery. This can be achieved using [DSN].
The mapping of fax addressing information to [MAIL] headers is described
Joffe, Wing, Kline Expires December 1997 [Page 6]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
in [FAX-ADDR].
6.1. ESMTP to SMTP Downgrading
To ensure a consistent level of service across an intranet or the global
Internet, it is essential that ESMTP servers support DSN at all hops
between a fax originating system and the recipient system.
However, in the situation where a 'downgrade' to an ESMTP server that
doesn't support DSN or to an SMTP server (which cannot support DSN) is
required, the SMTP client must send a "relayed" DSN to the originator
indicating loss of DSN, and continue to attempt to deliver the message.
See section 2.3.3 ("Action field") of [DSN] for more information.
This means sending systems must expect, in some cases, to receive
delivery failure notifications that aren't in DSN format.
7. CHUNKING, BINARYMIME, and 8BITMIME
Since fax images are large encoded binary data streams and scanning for
the final "." is not optimal, [BINARYMIME] and [8BITMIME] should be
considered when implementing fax-aware ESMTP servers, onramps, and
offramps.
The CHUNKING feature of [BINARYMIME] allows the ESMTP server to indicate
to the ESMTP client of reception problems without having to wait until
the ESMTP client has transmitted the entire message. With lengthy
faxes, and especially with Session mode (described in section 8),
CHUNKING can be a significant advantage.
8. Framework for immediate delivery support
The following service extension is defined for immediate (session mode)
delivery:
(1) The name of the immediate extension is "SESSION";
(2) the EHLO keyword value associated with the immediate extension
is "SESSION";
(3) one new SMTP verb, STAT, is defined with this extension, and is
described in section 10;
(4) one optional parameter is added to the RCPT command, using the
Joffe, Wing, Kline Expires December 1997 [Page 7]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
esmtp-keyword "SESSION", which is described in section 9;
(5) the maximum length of a RCPT TO is increased by 8 characters.
If an ESMTP server implements SESSION it should also implement
CAPABILITIES. If an ESMTP client uses SESSION and is attempting to
deliver a fax that exceeds baseline TIFF-F, it must request capabilities
(with the RCPT TO esmtp-keyword "CAPS").
9. RCPT TO:<forward-path> SESSION
A RCPT TO command issued by a client may also contain the esmtp-keyword
SESSION. This keyword indicates a request for session (immediate)
delivery, which would cause the ESMTP server to attempt immediate
delivery of the fax, or immediate connection with the next MTA in the
ESMTP path.
9.1. Response to esmtp-keyword SESSION
A RCPT command with the esmtp-keyword SESSION should only elicit a 250
reply if the ESMTP server is able to connect to the "next hop" (which
might be a real fax machine, or the next MTA in the ESMTP "path") and
after it begins communications with that "next hop" device or ESMTP
server.
9.2. Meaning of "250" reply to terminating "." with SESSION
When the ESMTP client sends the terminating "." (or BDAT LAST if using
CHUNKING from [BINARYMIME]), the "250" response from the ESMTP server
does _not_ indicate successful transfer of the message to the recipient.
It only indicates successful receipt of the data -- the data could still
be spooling to the recipient. The ESMTP client must use the STAT
command to query the progress and success/failure of the transfer to the
recipient.
9.3. SESSION-only ESMTP servers and non-session ESMTP clients
A legacy SMTP client (which doesn't support SESSION) may connect to an
ESMTP server that only supports SESSION and cannot do store-and-forward
(such as an offramp fax device with no disk drive).
In such a situation, the ESMTP server must:
(1) only respond to the terminating "." after the message has been
Joffe, Wing, Kline Expires December 1997 [Page 8]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
successfully or unsuccessfully received by the recipient.
(2) only one forward-path is allowed. If more than one forward-path
is sent in a single SMTP transaction they should be rejected with
a "421" response from the ESMTP server which will cause the
legacy SMTP client to retry sending the message later
(3) attempt to downgrade the fax, if necessary for the recipient's
fax machine. If such a downgrade is necessary but isn't possible
the ESMTP server should fail the transaction with a 5xx or use
the [ENH-CODES], if available.
10. New SMTP verb STAT
One new SMTP verb is introduced with the SESSION extension. The STAT
verb allows a client to query the progress of message transmission to
any SESSION mode recipient.
10.1. STAT verb
The STAT verb MUST be used by the ESMTP client to determine the success
or failure of a session-mode message.
An ESMTP client MUST NOT send a "STAT <forward-path>" command unless
both of the following conditions are true:
1. the RCPT command for that forward-path included the esmtp-keyword
SESSION, and
2. the ESMTP server responded to that forward-path with a 2xx
(success) reply code.
The syntax of the STAT verb, using the format described in [ABNF], is:
stat-cmd = "STAT" SP <forward-path> CR LF
10.1.1. Server reply to STAT
The ESMTP server's reply to STAT must be parsable by the ESMTP client
for possible presentation to the user via a progress indicator. The
replies must adhere to the following [ABNF] format:
stat-int-rsp = ( "250" / "55" DIGIT) SP
<forward-path> SP page-sent *text ";"
seconds-to-next-page SP text
Joffe, Wing, Kline Expires December 1997 [Page 9]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
page-sent = 1*5DIGIT
seconds-to-next-page = 1*5DIGIT
text = <any CHAR except CTL, DIGIT, and ";">
If the ESMTP server has finished or aborted transmission, "seconds-to-
next-page"
is zero. In no other cases shall "seconds-to-next-page" be zero.
Error code 550 is defined to inform a ESMTP client that fallback to
store and forward fax occurred. The client should disconnect from the
server since it already got a 250 response after the terminating "."
Error codes 551 through 555 are defined to support legacy receiving fax
devices. They are defined as:
551 busy
552 no answer
553 no carrier
554 unable to train
555 no confirmation received
Example responses:
Transmission not yet complete:
250 <+1-303-555-1212@gw.xerox.com> 3;40 seconds to page 4
250 <+1-303-555-1212@gw.xerox.com> 8;80
Transmission complete:
250 <+1-303-555-1212@gw.xerox.com> 4;0 complete
250 <+1-303-555-1212@gw.xerox.com> 10;0 complete
Transmission errors:
550 <+1-303-555-1212@gw.xerox.com> 5;0 fallback occurred
551 <+1-303-555-1212@gw.xerox.com> 0;0 busy
552 <+1-303-555-1212@gw.xerox.com> 0;0 no answer
553 <+1-303-555-1212@gw.xerox.com> 0;0 no carrier
554 <+1-303-555-1212@gw.xerox.com> 3;0 unable to train
555 <+1-303-555-1212@gw.xerox.com> 3;0 no page confirmation received
10.2. Implementation of fallback mode
In response to RCPT TO: <forward-path> SESSION
o the ESMTP server returns 250 if session mode is available and 450 if
there are no modem resources remaining for session delivery. If a
client gets a 450 response to RCPT TO, then the client can attempt s&f
Joffe, Wing, Kline Expires December 1997 [Page 10]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
or disconnect from the server.
In response to STAT:
o the client will know that session delivery failed and fallback to s&f
occurred when STAT returns 550. ("page-sent" is an accurate
indication of how many complete pages were sent in session mode before
fallback to s&f was invoked by the server.)
o the client will know that session delivery failed and s&f did not
occur when STAT returns 551 through 555. ("page-sent" is an accurate
indication of how many complete pages were sent in session mode before
failure occurred).
11. Examples
There are several proposals relating to the addressing format to be used
in Internet Fax. This RFC uses one of them in its examples, but the
actual format of the fax address is in [FAX-ADDR].
11.1. Session mode fax using BINARYMIME and CHUNKING:
S: 220 fsp.com SMTP service ready
C: EHLO isp.com
S: 250-fsp.com says hello
S: 250-CHUNKING
S: 250-BINARYMIME
S: 250-SESSION
S: 250 CAPABILITIES
C: MAIL FROM:<reverse-path>
S: 250 <reverse-path> sender OK
C: RCPT TO:<forward-path> SESSION CAPS
S: 250-<forward-path> recipient ok
S: 250-Accept: audio/basic
S: 250-Accept: text/html
S: 250-Accept: image/tiff;application=f, image/tiff;application=fx
S: 250-Accept-Features: papersize=na-letter, papersize=iso-a4
S: 250-Accept-Features: pix-x=1728, res=204x196
S: 250-Accept-Features: ttl=500
S: 250 Accept-Encoding: MH, MR, MMR, JBIG
C: BDAT 16384
C: Mime-Version: 1.0
C: Date: Wed, 19 Feb 1997 08:00 -0800
C: From: ABC Company <address> ;ABCCompany is the T.30 TSI
C: To: Jane Doe <address>
C: Subject: Renaming "ABC Company" to "BCD Company"
C: Content-type: image/tiff-f;application=f
Joffe, Wing, Kline Expires December 1997 [Page 11]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
C:
C: data..data..data
S: 250 OK 16384 bytes received
C: BDAT 16384
C: data..data..data
S: 250 OK 16384 bytes received
C: BDAT 8000 LAST
C: data..data..data
S: 250 OK 40768 bytes received
C: STAT <forward-path>
S: 250 <forward-path> 10;0 completed transmission
C: QUIT
S: 221 Goodbye
11.2. Session fax doesn't have outgoing modems available
The client tolerates this and falls back to store-and-forward faxing for
the session recipient, and also sends store-and-forward to other
recipients in the same transaction:
S: 220 fsp.com ESMTP service ready
C: EHLO isp.com
S: 250-fsp.com says hello
S: 250-SESSION
S: 250-DSN
S: 250 CAPABILITIES
C: MAIL FROM:<reverse-path> RET=HDRS ENVID=ZZ11111
S: 250 <reverse-path> Sender ok
C: RCPT TO:<forward-path1> CAPS SESSION
S: 450 <forward-path1> try later - no modems available
C: RCPT TO:<forward-path1> CAPS NOTIFY=SUCCESS,FAILURE,DELAY
S: 250-<forward-path1> Recipient ok
S: 250-Accept: image/tiff;application=f, image/tiff;application=fx,
application/octet-stream
S: 250-Accept-Features: papersize=na-letter, papersize=iso-a4
S: 250-Accept-Features: pix-x=728, res=204x196
S: 250-Accept-Features: ttl=620
S: 250 Accept-Encoding: MH, MR, MMR, JBIG
C: RCPT TO:<forward-path2> CAPS
S: 250-<forward-path2> Recipient ok
S: 250-Accept: image/tiff;application=f, image/tiff;application=fx,
application/octet-stream
S: 250-Accept-Features: papersize=na-letter, papersize=iso-a4
S: 250-Accept-Features: pix-x=1728, res=204x196
S: 250-Accept-Features: ttl=321
S: 250 Accept-Encoding: MH, MR, MMR, JBIG
C: DATA
Joffe, Wing, Kline Expires December 1997 [Page 12]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
S: 354 Enter your data
C: From: some user <address1>
C: To: another one <address2>, and more <address3>
C: Date: Mon, 1 Jan 1990 08:00 -0800
C: Subject: Green Beans
C: Mime-Version: 1.0
C: Content-Type: image/tiff-f;application=f
C:
C: data.data.data
C: data.data.data
C: data.data.data
C: .
S: 250 message accepted
C: QUIT
S: 221 Goodbye
11.3. Fax-aware ESMTP client talking to legacy SMTP server
S: 220 oldstyle.com SMTP service ready
C: EHLO isp.com
S: 500 Syntax error, command unrecognized
C: HELO isp.com
S: 250 Hi there, isp.com, this is oldstyle.com
C: MAIL FROM:<reverse-path>
S: 250 <reverse-path> Sender ok
C: RCPT TO:<forward-path>
S: 250 <forward-path> Okay
C: DATA
S: 354 Enter your data
C: From: some user <address1>
C: To: another one <address2>, and more <address3>
C: CC: and just one more <address4>
C: Date: Mon, 1 Jan 1990 08:00 -0800
C: Subject: Green Beans
C: Mime-Version: 1.0
C: Content-Type: image/tiff-f;application=f
C:
C: data.data.data
C: data.data.data
C: data.data.data
C: .
S: 250 message accepted for delivery
C: QUIT
S: 221 Goodbye
Fax-aware ESMTP client would then have to send a DSN to the originator
indicating loss of DSN at this hop (section 6.1).
Joffe, Wing, Kline Expires December 1997 [Page 13]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
11.4. Legacy SMTP client sending to fax-aware ESMTP server
ESMTP server is only able to send immediately (session mode) -- it
cannot store and forward because it has no disk drive.
11.4.1. Successful transmission (one recipient)
S: 220 gizmo.cisco.com FAX offramp ESMTP server ready
C: HELO sendmail.cisco.com
S: 250 Hi there, sendmail.cisco.com, I do fax
C: MAIL FROM:<reverse-path>
S: 250 <reverse-path> Sender ok
C: RCPT TO:<address@gizmo.cisco.com>
S: 250 <address@gizmo.cisco.com> Okay
C: DATA
S: 354 Enter your data
C: From: some user <address1>
C: To: another one <address2>
C: CC: and more <address3>
C: Date: Mon, 1 Jan 1990 08:00 -0800
C: Subject: Green Beans
C: Mime-Version: 1.0
C: Content-Type: image/tiff-f;application=f
C:
C: data.data.data
C: data.data.data
C: data.data.data
C: . (SMTP server doesn't respond until fax is delivered)
S: 250 fax delivered to <forward-path>
C: QUIT
S: 221 Goodbye
11.4.2. Offramp-only gateway
This is unsuccessful because SMTP client was misconfigured and tried to
relay through SESSION-only ESMTP server (gizmo.cisco.com).
S: 220 gizmo.cisco.com FAX offramp ESMTP server ready
C: HELO sendmail.cisco.com
S: 250 Hi there, sendmail.cisco.com, I do fax
C: MAIL FROM:<reverse-path>
S: 250 <reverse-path> Sender ok
C: RCPT TO:<address1@otherbox.cisco.com>
S: 550 <address1@otherbox.cisco.com> relaying not permitted
C: RCPT TO:<address2@anotherbox.cisco.com>
S: 550 <address2@anotherbox.cisco.com> relaying not permitted
Joffe, Wing, Kline Expires December 1997 [Page 14]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
C: QUIT
S: 221 Goodbye
11.4.3. Legacy SMTP client is forced to retry when sending to more than
one recipient
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 gizmo.cisco.com FAX offramp ESMTP server ready
C: HELO sendmail.cisco.com
S: 250 Hi there, sendmail.cisco.com, I do fax
C: MAIL FROM:<reverse-path>
S: 250 <reverse-path> Sender ok
C: RCPT TO:<address1@otherbox.cisco.com>
S: 250 <address1@otherbox.cisco.com> Recipient ok
C: RCPT TO:<address2@anotherbox.cisco.com>
S: 450 <address2@anotherbox.cisco.com> Try again later
C: DATA
S: 354 Enter your data
C: From: some user <address1>
C: To: another one <address2>
C: CC: and more <address3>
C: Date: Mon, 1 Jan 1990 08:00 -0800
C: Subject: Green Beans
C: Mime-Version: 1.0
C: Content-Type: image/tiff-f;application=f
C:
C: data.data.data
C: data.data.data
C: data.data.data
C: . (SMTP server doesn't respond until fax is delivered)
S: 250 fax delivered to <forward-path>
C: QUIT
S: 221 Goodbye
11.4.4. Mixed mode fax example with multiple recipients:
S: 220 Welcome to gw.cisco.com
C: EHLO fax.symantec.com
S: 250-This is gw.cisco.com
S: 250-DSN
S: 250-CAPABILITIES
S: 250 SESSION
C: MAIL FROM: <+1-416-446-8022@fax.symantec.com> RET=HDRS
ENVID=SYMFAX1234
S: 250 <+1-416-446-8022@fax.symantec.com> sender ok
Joffe, Wing, Kline Expires December 1997 [Page 15]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
C: RCPT TO: <+1-408-526-7544@gw.cisco.com> CAPS SESSION
S: 250-<+1-408-526-7544@gw.cisco.com> recipient ok
... recipient capabilities advertised by server
C: RCPT TO: <+1-408-526-7000@gw.cisco.com> CAPS
NOTIFY=SUCCESS,FAILURE,DELAY
S: 250-<+1-408-526-7000@gw.cisco.com> recipient ok
... recipient capabilities advertised by server
12. Security Considerations
To provide greater security for faxes than that is commonly perceived to
exist in the telephone network, fax-aware network devices should
implement security extensions, such as [MIME-PGP], [MIME-SEC] or
[SMIME], which can encrypt a message end-to-end, including while it
resides on the storage device of a store-and-forward mailer. Both
security extensions reduce the likelihood of forged messages as well.
Forged sender information is possible with [SMTP], and it is recommended
that implementations preserve Received: headers for tracking forged
messages whenever possible.
13. Implementation notes
This section contains notes to implementers.
13.1. Aborting a fax
If the user wishes to abort a fax transmission the ESMTP client may
simply drop the TCP connection, as there is no way to send a command
while sending the message data.
13.2. ESMTP server response to STAT
If the ESMTP server receives a STAT command for a forward-path sooner
than the 'seconds-to-next' value that the ESMTP server sent in response
to the last query for that specific forward-path, the ESMTP server may
delay responding to the STAT command until 'seconds-to-next' has
elapsed. This is done to prevent ESMTP clients from querying the ESMTP
server for status updates when no new information is available.
13.3. ESMTP client pipelining STAT commands
The ESMTP client may use [PIPELINING] for its STAT commands. The group
Joffe, Wing, Kline Expires December 1997 [Page 16]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
of STAT commands for each of the forward-paths in this transaction may
be considered a pipelined command group. The ESMTP client should wait
for the response to the last STAT for that pipelined command group
before sending other commands.
14. Acknowledgments
This document was produced by the Internet Fax Working Group. The
authors wish to thank (a bunch of people).
15. References
[8BITMIME]
Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D.,
"SMTP Service Extension for 8bit-MIMEtransport", RFC 1652,
July 1994.
[ABNF]
Crocker, D., "Augmented BNF for Syntax Specifications: ABNF",
Internet Draft, Work in Progress, draft-ietf-drums-abnf-02.txt,
January 1997.
[BFT]
International Telecommunication Union, Binary File Transfer
Format for the Telematic Services", ITU recommendation T.434,
http://www.itu.int/itudoc/itu-t/rec/t/t434_23179.html, 1996.
[BFT-FAQ]
Computer Facsimile Committee, "Facsimile Binary File Transfer
Frequently Asked Questions",
http://www.ema.org/html/at_work/committe/faqbft.htm, October
1996.
[BINARYMIME]
G. Vaudreuil, "SMTP Service Extensions for Transmission of Large
and Binary MIME Messages", Experimental, RFC 1830, August 1995.
[DSN]
Moore, K., Vaudreuil, G., "An Extensible Message Format for
Delivery Status Notifications", RFC 1894, January 1996.
[ENH-CODES]
Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
January 1996.
[ENH-RET]
Joffe, Wing, Kline Expires December 1997 [Page 17]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
Freed, N., "SMTP Service Extension for Returning Enhanced Error
Codes", RFC 2034, October 1996.
[FAX-ADDR]
TBD (IETF-FAX WG), "SMTP Addressing and Headers for Internet
FAX", Work in Progress, no draft currently available.
[HOST-REQ]
Braden, R., Editor, "Requirements for Internet Hosts --
Application and Support", STD 3, RFC 1123, October 1989.
[HTTP-ATTR]
Mutz, A., Montulli, L., Masinter, L., Holtman, K., "User-Agent
Display Attributes", Internet Draft, Work In Progress,
draft-mutz-http-attributes-02.txt, November 1996 (EXPIRED).
[HTTP-HEAD]
Fielding, R., et al, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997.
[MAIL]
Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD-11, RFC 822, August 1982.
[MIME-SEC]
Crocker, S., Freed, N., Galvin, J., Murphy, S., "MIME Object
Security Services", RFC 1848, October 1995.
[MIME-PGP]
Elkins, M., "MIME Security with Pretty Good Privacy (PGP)", RFC
2015, October 1996.
[PDF]
Bienz, T., Cohn, R., and Meehan, J., "The Portable Document
Reference Manual", Revised Edition, ISBN 0-201-62628-4, March
1996.
[PIPELINING]
Freed., N., Cargille, A., "SMTP Service Extension for Command
Pipelining", RFC 1854, October 1995.
[SMIME]
Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., Repka, L.,
"S/MIME Message Specification", Internet Draft, Work In Progress,
draft-dusse-smime-msg-02.txt, July 1997.
[SMTP]
Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
Joffe, Wing, Kline Expires December 1997 [Page 18]
INTERNET-DRAFT ESMTP Capabilities and Immediate Delivery July 1997
August 1982.
[SMTP-EXT]
Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker, D.,
"SMTP Service Extensions", STD 10, RFC 1869, November 1995.
[T.30]
International Telecommunication Union, "Procedures for document
facsimile transmission in the general switched telephone
network", ITU recommendation T.30,
http://www.itu.ch/itudoc/itu-t/rec/t/t30_23540.html, July 1996.
[TIFF-F]
Parsons, G., Rafferty, J., "Tag Image File Format (TIFF) -
Application F", Internet Draft, Work In Progress,
draft-ietf-fax-tiff-02, July 1997.
[TIFF-FX]
McIntyre, L., Zilles, S., "File Format for Internet Fax",
Internet Draft, Work In Progress, draft-ietf-fax-tiffplus-00,
March 1997.
16. Author's Addresses
Neil Joffe
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Tel: +1 408 526 4000
Email: njoffe@cisco.com
Dan Wing
Cisco Systems, Inc.
101 Cooper Street
Santa Cruz, CA 95060
USA
Tel: +1 408 457 5200
Email: dwing@cisco.com
Charles Kline
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
Tel: +1 408 526-4000
Email: ckline@cisco.com
Joffe, Wing, Kline Expires December 1997 [Page 19]
