Open philipwhiuk opened 7 years ago
What do you mean by "often slow due to the need to line-wrap content"? What exactly should be different when sending the message in chunks? BINARYMIME + BDAT allows sending 8-bit parts, e.g. attachments without base64 encoding. However, I don't know of any clients that actually do this. I'm not even sure if we support receiving such messages.
Hmm odd.
The RFC is kind of annoying in that they are both specified in one RFC and the pre-amble makes statements where it's unclear whether you need both for the benefit.
Gmail advertises CHUNKING without BINARYMIME and reading the RFC I assumed CHUNKING got rid of all CRLF stuff.
But it actually looks like it's mostly an efficiency to avoid the ending:
.<CR><LF>
So I guess it's a fairly minor improvement.
As for BINARYMIME, G-Mail doesn't support it, but Outlook does (along with chunking).
The support of CHUNKING without BINARYMIME is also explained in the Postfix documentation: https://www.postfix.org/BDAT_README.html
Sending large messages over SMTP is often slow due to the need to line-wrap content.
The CHUNKING extension (RFC 3030) allows for a BDAT command to replace the DATA command. This allows for messages to be sent as continual chunks of data rather than line-wrapped.
It is supported by Gmail and other providers.
Implementation of this will need to be aware of the PIPELINE extension (see #2338) and 8BITMIME extension.
We will need to pick an appropriate chunk size. This might involve investigation of what other providers use (the RFC uses 100000 but it's unclear whether this figure was arbitrarily chosen). It seems over-the-top to allow it to be configurable.
Obviously if the extension instead present we will need to use the normal data command.
Tests should cover use and lack of the extension, as well interaction with PIPELINING