rfc1845.txt

用C#开发实现SMTP相关技术,能接收到带附件的邮件服务功能.

Network Working Group                                         D. Crocker
Request For Comments: 1845                        Brandenburg Consulting
Category: Experimental                                          N. Freed
                                            Innosoft International, Inc.
                                                   A. Cargille, WG Chair
                                                          September 1995


                         SMTP Service Extension
                         for Checkpoint/Restart

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  This memo does not specify an Internet standard of any
   kind.  Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Abstract

   This memo defines an extension to the SMTP service whereby an
   interrupted SMTP transaction can be restarted at a later time without
   having to repeat all of the commands and message content sent prior
   to the interruption.

1.  Introduction

   Although SMTP is widely and robustly deployed, various extensions
   have been requested by parts of the Internet community. In
   particular, when dealing with very large messages over less reliable
   connections it is possible for substantial resources to be consumed
   by repeated unsuccessful attempts to transmit the message in its
   entirety. The original SMTP specification [1] does not provide any
   means to pick up a partially completed transaction after the
   underlying TCP connection has been broken and reestablished.

   This memo provides a facility by which a client can uniquely identify
   a particular SMTP transaction. The server then stores this
   identifying information along with all the information it receives as
   the transaction proceeds. If the transaction is interrupted during
   the data transfer phase the SMTP client may establish a new SMTP
   session at a later time and ask the server to continue the
   transaction from the point where the server lost its connection with
   the client. The server then reestablishes the transaction context and
   tells the client where to resume operations. If this is acceptable
   the client resumes operations at this point.





Crocker, Freed & Cargille     Experimental                      [Page 1]

RFC 1845                SMTP Checkpoint/Restart           September 1995


   This extension may also be used to work around the common timeout
   problem where a client times out waiting for a response from the
   server acknowledging that the message has been accepted. However, use
   of this extension is not an acceptable substitute for proper setting
   of timeout parameters.

2.  Framework for the Checkpointing Extension

   The checkpointing extension is laid out as follows:

 (1)   the name of the SMTP service extension defined here is
       checkpointing;

 (2)   the EHLO keyword value associated with the extension is
       CHECKPOINT;

 (3)   no parameter is used with the CHECKPOINT EHLO keyword;

 (4)   one optional parameter using the keyword TRANSID is
       added to the MAIL FROM command.  The value associated
       with this parameter, coupled with the name of the
       client taken from EHLO command, forms a globally unique
       value that identifies this particular transaction and
       serves to distinguish it from all others. This value is
       case-sensitive. The syntax of the value is as follows,
       using the ABNF notation of [2]:

            transid-value  ::= "<" transid-spec ">"
                               ; transid-value may not be longer than
                               ; 80 characters
            transid-spec   ::= transid-local "@" transid-domain
            transid-domain ::= transid-token
            transid-local  ::= transid-token
            transid-token  ::= transid-atom *("." transid-atom)
            transid-atom   ::= 1*<any (ASCII) CHAR except SPACE,
                                  CTLs, tspecials, or ".">

       NOTE: tspecials is defined in [3]. The TRANSID is
       likely to be different from the RFC822 message id,
       since it must uniquely identify the particular copy of
       the message being sent over this SMTP link. However,
       the syntax of transid-value is designed so that any
       TRANSID is both a legal RFC822 msg-id as well as being
       a legal esmtp-value [4].

 (5)   The maximum length of a MAIL FROM command line is
       increased by 88 characters by the possible addition of
       the TRANSID keyword and value;



Crocker, Freed & Cargille     Experimental                      [Page 2]

RFC 1845                SMTP Checkpoint/Restart           September 1995


 (6)   no additional SMTP verbs are defined by this extension;
       and,

 (7)   the next section specifies how support for the
       extension affects the behavior of a server and client
       SMTP.

3.  The checkpointing service extension

   When a client SMTP wishes to use checkpointing to eliminate the need
   to retransmit all message data in its entirety in the event of a
   session interruption, it first issues the EHLO command to the server
   SMTP. If the server SMTP responds with code 250 to the EHLO command,
   and the response includes the EHLO keyword value CHECKPOINT, then the
   server SMTP is indicating that it supports SMTP checkpointing and
   will honor requests to restart interrupted SMTP transactions.

   The extended MAIL command is issued by a client SMTP when it wishes
   to enable server checkpointing. The syntax for this command is
   identical to the MAIL command in [1], except that a TRANSID parameter
   must appear after the address.

   The complete syntax of this extended command is defined in [4], with
   the esmtp-keyword TRANSID and transid-value parameter as previously
   defined.

   The value associated with the TRANSID parameter must be an identifier
   that serves to uniquely identify this particular SMTP transaction.
   Only one TRANSID parameter may be used in a single MAIL command. Care
   must be used in constructing TRANSID values to simultaneously insure
   both uniqueness and the ability to reidentify interrupted
   transactions.

   The TRANSID is structured to ensure globally uniqueness without any
   additional registry. The transid-domain part should be a valid domain
   name that uniquely identifies the SMTP client. Note that this is
   usually the same as the domain name given in conjunction with the
   EHLO command, but not always. The EHLO domain name identifies the
   specific host the SMTP connection originated from, whereas the
   transid-domain may refer to a group of hosts that collectively host a
   multi-homed SMTP client. The transid-local part should be an
   identifier that distinguishes this SMTP transaction from any other
   originating from this SMTP client.

   Despite the structured nature of the TRANSID the server should treat
   the value as an opaque, case-sensitive string.





Crocker, Freed & Cargille     Experimental                      [Page 3]

RFC 1845                SMTP Checkpoint/Restart           September 1995


   Note that the contents of the RFC822 message-id header typically are
   NOT appropriate for use as the TRANSID parameter value, since such
   identifiers may be associated with multiple copies of the same
   message -- e.g., as it is split during transmission down different
   network paths -- and hence with multiple distinct SMTP transactions.

   A server which supports the checkpointing extension will then retain
   the transaction identifer as well as the most recent state of the
   transaction in non-volatile storage. This information should deleted
   only when the transaction is known to be complete from the client's
   perspective. Completion is assured only when the client either
   explicitly aborts the transaction, starts a new transaction, or
   requests that the connection be closed with a QUIT command.

   In the event of an interruption prior to completing a transaction
   this preserved state will remain for some period of time defined by
   the operational policies of the server administrator. It is
   recommended that transaction state information be preserved for at
   least 48 hours, although no specific time is required.

   When a client detects that a transaction has been interrupted, it
   then must wait for some period before reconnecting. This period must
   be long enough for server connections to time out and for the
   transaction state associated with such connections to be released for
   use by a new connection. The Internet Host Requirements [5] also