More SMTP optimization

[fanf]

A couple of weeks ago I was working on the SMTP QUICKSTART specification, which optimizes the start of the SMTP connection.

http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-quickstart.html

I have now written a specification for SMTP transaction replay, which allows you to use the existing CHUNKING and PIPELINING extensions to acheive the maximum speed possible for bulk data transfer, whilst still behaving correctly if the connection is lost. I imagine this will be most useful clients on slow intermittent links, like mobile wireless users or people on the wrong end of a satellite link.

http://www-uxsup.csx.cam.ac.uk/~fanf2/hermes/doc/qsmtp/draft-fanf-smtp-replay.html

Gosh, over 5000 words...

Comments

[pm215]

Interesting. If you happen to have a cooperating client and server (as you might well in the mobile phone case, say) are you allowed to implement your own private SMTP extensions, or are you obliged to wait for them to become proper RFCs?

there's a typo (REPLAT) in s10.1, BTW...

[fanf]

Yes, private extensions are permitted. (Though you are supposed to use names starting woth X for non-standards-track extensions.)