rfc1845.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   use by a new connection. The Internet Host Requirements [5] also
   impose restriction on how quickly reconnection attempts can be made
   (section 5.3.1.1).

   Once the necessary period has elapsed the client first checks the DNS
   as described in [6] and determine the set of acceptable IP addresses
   the message can be transferred to. If the IP address used to connect
   to the original server is still on this list it should be tried
   first, since this server is most likely to be capable of restarting
   the transaction. If this connection attempt fails the client must
   then proceed as described in [6] to try all the remaining IP
   addresses and restart the transaction there. If the attempt to
   restart fails on one of the other servers the client is required to
   retransmit the transaction in its entirety at that point.  Waiting
   for a server with an interrupted transaction state to come back
   online is not acceptable.

   Note: Multi-homed SMTP servers do exist, which means that it is
   entirely possible for a transaction to restart on a different server
   host.

   Once the connection is made the client issues the same MAIL command
   with exactly the same transaction identifier. If the transaction was
   interrupted during or at the end of the transfer of actual message



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


   data, the server first reestablishes its context to a point close as
   possible to the point of interruption and then responds with the
   status message:

     355 octet-offset is the transaction offset

   The actual status text can vary. However the octet-offset field is
   required to be the first thing on the first line of the reply, it
   must be separated from any following text by linear whitespace, and
   it is structured as follows:

     octet-offset ::= 1*DIGIT

   The octet-offset represents an offset, counting from zero, to the
   particular octet in the actual message data the server expects to see
   next. (This is also a count of how many octets the server has
   received and stored successfully.) This offset does NOT account for
   envelope data, i.e., MAIL FROM and RCPT TO commands. A value of 0
   would indicate that the client needs to start sending the message
   from the beginning, a value of 1 would indicate that the client
   should skip one octet, and so on.

   The SMTP canonical format for messages is used when this offset is
   computed.  Any octets added by any SMTP data-stuffing algorithm do
   not count as part of this offset. In the case of data transferred
   with the DATA command the offset must also correspond to the
   beginning of a line.

   Once this context is reestablished the client issues another data
   transfer command (e.g., DATA) and sends the remaining message data.
   Once this data is terminated the transaction completes in the normal
   fashion and the server deletes the transaction context from non-
   volatile storage.

   Note that the semantics of the octet-offset immediately suggest a
   particularly simple implementation strategy, where the client
   retransmits the message data as it normally would but suppresses
   output of the first octet-offset octets of material. The semantics
   used here are intentionally designed to make such implementation
   possible, but care must be taken to insure that such an
   implementation strategy does not impose a significant performance
   penalty on the client.









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


5.  Usage Example

   The following dialogue illustrates the use of the checkpointing
   service extension:

S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-dbc.mtview.ca.us says hello
S: 250 CHECKPOINT
C: MAIL FROM:<[e-mail]> TRANSID=<[e-mail]>
S: 250 <[e-mail]>... Sender and TRANSID ok
C: RCPT TO:<[e-mail]>
S: 250 <[e-mail]>... Recipient ok
C: DATA
S: 354 Send checkpointed message, ending in CRLF.CRLF
<some amount of message data transmitted>
<session is interrupted and TCP connection is broken>

Some time later a new connection is established:
S: <wait for connection on TCP port 25>
C: <open connection to server>
S: 220 dbc.mtview.ca.us SMTP service ready
C: EHLO ymir.claremont.edu
S: 250-dbc.mtview.ca.us says hello
S: 250 CHECKPOINT
C: MAIL FROM:<[e-mail]> TRANSID=<[e-mail]>
S: 355 6135 is the transaction offset
C: DATA
S: 354 Send previously checkpointed message starting at octet 6135
C: <message data minus first 6135 octets sent>
C: .
S: 250 OK
C: QUIT
S: 221 Goodbye

6.  Security Considerations

   This RFC does not discuss security issues and is not believed to
   raise any security issues not already endemic in electronic mail and
   present in fully conforming implementations of [1].









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


7.  References

   [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
       USC/Information Sciences Institute, August 1982.

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

   [3] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
       Extensions", RFC 1521, Bellcore, Innosoft, September 1993.

   [4] Rose, M., Stefferud, E., Crocker, D., Klensin, J., and N. Freed,
       "SMTP Service Extensions", RFC 1651, Dover Beach Consulting,
       Inc., Network Management Associates, Inc., Silicon Graphics,
       Inc., MCI, Innosoft, July 1994.

   [5] Braden, R., Editor, "Requirements for Internet Hosts -
       Application and Support", STD 3, RFC 1123, USC/Information
       Sciences Institute, October 1989.

   [6] Partridge, C., "Mail Routing and the Domain System", STD 14, RFC
       974, BBN, January 1986.

8.  Authors' Addresses

       Dave Crocker
       Brandenburg Consulting
       675 Spruce Dr.
       Sunnyvale, CA 94086 USA
       USA

       Phone: [phone]
       Fax: [phone]
       EMail: [e-mail]


       Ned Freed
       Innosoft International, Inc.
       1050 East Garvey Avenue South
       West Covina, CA 91790
       USA

       Phone: [phone]
       Fax: [phone]
       EMail: [e-mail]






Crocker, Freed & Cargille     Experimental                      [Page 7]