![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
On Sun, 05 Aug 2001 19:39:21 +1200, Franck Martin <franck at sopac.org> said: > 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... 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
Attachment:
pgp00itQDi5lL.pgp
Description: PGP signature
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.