HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 02:26:34 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Mon, 14 Jul 1997 15:49:00 GMT ETag: "2ed9d0-88f2-33ca4a6c" Accept-Ranges: bytes Content-Length: 35058 Connection: close Content-Type: text/plain 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 . 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: 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 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 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: 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 " 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 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 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 = 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: 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: S: 250 sender OK C: RCPT TO: SESSION CAPS S: 250- 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
;ABCCompany is the T.30 TSI C: To: Jane Doe
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 S: 250 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: RET=HDRS ENVID=ZZ11111 S: 250 Sender ok C: RCPT TO: CAPS SESSION S: 450 try later - no modems available C: RCPT TO: CAPS NOTIFY=SUCCESS,FAILURE,DELAY S: 250- 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: CAPS S: 250- 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 C: To: another one , and more 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: S: 250 Sender ok C: RCPT TO: S: 250 Okay C: DATA S: 354 Enter your data C: From: some user C: To: another one , and more C: CC: and just one more 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: S: 250 Sender ok C: RCPT TO: S: 250 Okay C: DATA S: 354 Enter your data C: From: some user C: To: another one C: CC: and more 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 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: S: 250 Sender ok C: RCPT TO: S: 550 relaying not permitted C: RCPT TO: S: 550 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: C: 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: S: 250 Sender ok C: RCPT TO: S: 250 Recipient ok C: RCPT TO: S: 450 Try again later C: DATA S: 354 Enter your data C: From: some user C: To: another one C: CC: and more 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 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]