Summary

  • RFC 1845 proposed an Experimental SMTP extension in 1995: CHECKPOINT advertised support, TRANSID identified one mail transaction, and the server retained partial state in nonvolatile storage.
  • Its illustrative exchange restarted with 355 6135, meaning the server had stored 6,135 octets of message data. The offset excluded envelope commands and SMTP dot-stuffing, and a DATA restart had to begin on a line boundary.

Picture a large message crossing a shaky link. The TCP connection drops near the end, so the sender reconnects and sends everything again. Another drop makes it start over once more. That was the practical bill behind RFC 1845. Original SMTP could deliver mail, but it had no checkpoint for a partially transmitted transaction. D. Crocker, N. Freed and A. Cargille proposed one in September 1995. Their document was Experimental; the worked dialogue is a protocol example, not an incident report.

The repair started before any data moved. The sending server asked EHLO; a receiving server willing to save progress replied with CHECKPOINT. The sender then put a TRANSID parameter on MAIL FROM. This identifier was for one particular transfer across an SMTP link. It was case-sensitive and opaque to the receiver. The ordinary message's Message-ID could describe several copies travelling by different paths, so it could not safely stand in for that transfer identity. A human might call them the same email; the wire had several transactions to distinguish.

With an identified transaction, the receiving server had to keep more than a cheerful acknowledgement. It stored the transaction identifier and latest state in nonvolatile storage. The RFC recommended retaining interrupted state for at least 48 hours, leaving the actual period to local policy. Storage was the server's side of the bargain: a restart number from a lost in-memory counter would be theatre. The client, meanwhile, had to wait for old connections to time out, check current DNS destinations, try the original still-acceptable address first, then other eligible servers.

If another server could not resume, the client resent the transaction rather than holding delivery hostage to the old machine's return.

In the RFC's sample, the resumed MAIL FROM carries exactly the same TRANSID. The receiver answers 355 6135 is the transaction offset. That 6,135 counts successfully stored message-data octets. It does not count MAIL FROM or RCPT TO, nor the extra bytes SMTP adds when dot-stuffing data lines. With DATA, the restart point must also be the beginning of a line. The sender cannot point at byte 6,135 in an arbitrary file and hope it means the same thing; it must reproduce SMTP's canonical message-data stream.

Then the exchange becomes wonderfully boring. The sender issues DATA, omits the first 6,135 octets already held by the receiver, sends the remainder and receives 250 OK. The RFC even allows an implementation to regenerate the full stream locally and suppress output until it reaches the offset. That is less clever than seeking through a raw file, but it respects the exact counting rule. A checkpoint bought less retransmission only because both sides shared a definition of what had been counted.

The number was a receipt with sharp edges. It vouched for the bytes stored in that transaction, under that server's retained state. It said nothing about a recipient opening the message, and it was not a universal name for the message. RFC 1845's cleverness lay in refusing to make one identifier or one acknowledgement do all those jobs. The connection could die; the definition of progress had to survive it.