![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
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 Franck at sopac.org
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.