Subject: Resume command for ESMTP?

From: Franck Martin <[email-masked]>
Date: 05 Aug 2001 19:39:21 +1200

Hi all,

I'm a newbie on IETF, so please be nice ;-)

I have been looking around, but cannot find a resume command for ESMTP.
If it already exists thanks to give me the RFC, unless I'm keen to write
an RFC something...

The problem, is that in many place where there is poor bandwidth and
network (like where I am), many SMTP sessions gets disconected before
the transaction is finished. It leads that the server will have to
restart from the beginning...

It becomes a problem even more so that longer e-mails will have less and
less chance to be sent ( Ithink the function is exponential). So the
solution at the moment is to limit the size of the e-mail that can be
sent or received. So the size fits inside a good session time without
errors(kind of MTU)...

But all the other protocols now have the possibility to resume the
transfer like HTTP or FTP but not SMTP.

You know, that more and more users are using mail as a file transfer
protocol, and asking them to put the file on a ftp/http site or split it
in parts is out of most internet user capability nowadays. Moreover when
you tell them that you have a 500kB mail limit they think you are a
dinosaur!

So ESMTP could have an extension called RESUME

The protocol would be standard, except that before DATA and after RCPT
TO, the sending server who has identified the RESUME keyword could ask a
RESUME session...

...
->RESUME
<-SESSION 34dc563450 0
->DATA
...

If the connection break, then the sending server restablishes the
connection, goes through the same handshake and before DATA but after
RCPT TO does:

...
->RESUME 34dc563450
<-SESSION 34dc563450 346890
->DATA
...

The 346890 is the number of bytes the receiver has successfully
received...

There would be some various error cases, security checking and other
possibilities but before I spend too much time on that, what do you
think?

Cheers
[email-masked]

---

From: [email-masked]
Date: Sun, 05 Aug 2001 15:44:34 -0400

> TO, the sending server who has identified the RESUME keyword could ask a

For FTP and HTTP, most transfers are *DOWNLOADS* - which means that the server
has *already* committed space on stable storage to hold the file on at least
a semi-permanent basis.  If it *is* an upload you are trying to resume, the
user is most likely uploading to *his* storage space, which is likely
quota-protecteed in some way.

On the other hand, SMTP is a store-and-forward system where the files are
kept in essentially *temporary* storage.  As such, the general design
philosophy is to throw away the temporary files if a transfer fails, so
as to free up queue space.

This in and of itself is not a problem, until you realize that quite possibly
more than one file may need to be saved in case the person will *someday*
try to RESUME the transfer.  Now.. a real-life case in point.

Our mail server is getting hit *thousands* of times a day with variants
of the SirCam virus. Many of these transfers fail.  Currently, our mail
server would just toss the files related to the failed transfer - if it
supported RESUME it would have to keep them around.

It's call a 'denial of service attack'.  Feed the victim lots of large files
they have to keep around, and then leave and watch the fun as their mail
server runs out of queue space.

And that's why there isn't a RESUME.

-- 
				Valdis Kletnieks
				Operating Systems Analyst
				Virginia Tech

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 05 Aug 2001 16:14:36 -0600

> If it already exists thanks to give me the RFC, unless I'm keen to write

"SMTP Service Extension for Checkpoint/Restart" RFC 1845.

Alexey Melnikov
__________________________________________
R & D, ACI Worldwide (formerly MessagingDirect Ltd.)
phone 780.424.4922 x357

I speak for myself only, not for my employer.
__________________________________________

---

From: [email-masked]
Date: Sun, 05 Aug 2001 20:26:14 -0400

> "SMTP Service Extension for Checkpoint/Restart" RFC 1845.

Damn.  How did that sneak by me? ;)

/Valdis