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

[fanf]

Will the client be allowed to switch between smtps and starttls, or between ports (25, 587, 465), as long as they always use TLS ? I'm thinking about the case where my mobile ISP happily allows port 25 but the connection dies so I retry over my home ISP which blocks port 25 ?

From the IETF's point of view, smtps doesn't exist :-) But switching between ports 25 and 587 on the same submission server should be OK. I expect that actual implementations will treat 465 the same way as 587+STARTTLS.

Are message-size values typically accurate to the octet ? I remember bugs in exim where it wasn't always correctly updated - I think for header-rewrites. Clearly this is a problem with the submitting application, but if it is common it could reduce take up of replay.

A good point. Another area where byte counts get tricky is when using the Lemonade BURL extension, which allows you to compose a message on an IMAP server e.g. so that you can forward an attachment without downloading and uploading it again. The message is submitted by passing a self-authorizing URL to the message submission server which retrieves it from the IMAP server. (This avoids embedding SMTP+extensions within IMAP.) BURL can be combined with BDAT to provide the message header, new message content, and MIME framing for a forwarding attachment. I think I'll see what others have to say before tackling the problem :-)

This sounds as though, while the accept/reject decision is in flight, the server considers the message "complete" but the client considers it "partial". I take it that that isn't what you mean.

That's exactly what I mean. The discrepancy reflects the fact that different parts of a distributed can have different views of the status of a transaction and will need to roll back or forwards to become consistent. I'll add a clarification.

Thanks for the feedback.