Browse Prior Art Database

SMTP Service Extension for Checkpoint/Restart (RFC1845) Disclosure Number: IPCOM000004101D
Original Publication Date: 1995-Sep-01
Included in the Prior Art Database: 2019-Feb-12
Document File: 7 page(s) / 10K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

D. Crocker: AUTHOR [+2]

Related Documents

10.17487/RFC1845: DOI

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 23% of the total text.

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.


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]: