Full 8BITMIME support in mimemail / smtp_client

[seriyps]

Not really an issue, but a proposal / improvement suggestion.

Currently our gen_smtp_server does support 8-bit DATA payload (it advertises 8BITMIME extension https://datatracker.ietf.org/doc/html/rfc6152). After #280 we started to support utf-8 email addresses https://datatracker.ietf.org/doc/html/rfc6531. As far as I understand, our mimemail:decode/1 also supports MIME-messags which are 8-bit (but it seems we don't have tests ensuring that it works correctly?).

But there are several RFCs describing the ways of how to mime-encode and transfer via SMTP 8-bit/utf8 payloads:

• https://datatracker.ietf.org/doc/html/rfc6532 "Internationalized Email Headers" explains how to use UTF-8 encoded header values without quoted-printable/base64 encoding
• https://datatracker.ietf.org/doc/html/rfc2045#section-6 that describes Content-Transfer-Encoding: 8bit
• https://datatracker.ietf.org/doc/html/rfc6152 "SMTP Service Extension for 8-bit MIME Transport" explains how such payloads could be transported over SMTP

I think we should try to implement some support for those specifications in our mimemail encoder as well as gen_smtp_client.

However, it might be a bit tricky, because smtp client could only detect if it's allowed to send 8-bit payloads after it connected to the SMTP server and received EHLO response advertising 8BITMIME (and, optionally, SMTPUTF8) extension. So we can't encode mime message with 8-bit coding without consulting the receiving server first; that means gen_smtp_client have to have some 2-stage API where we discover if it suports 8-bit, then do mime encoding and then send the payload. One option is to use gen_smtp_client:open/1 which returns (opaque) gen_smtp_client:smtp_client_socket(), and this structure already contains information about extensions supported by the server - we just need to implement some getter function for this field.

[juhlig]

I wouldn't go that way, it's a can of worms ;) I'm working in the E-Mail sending business, and we explored this at one point in the past, but then decided it's just way more trouble than it's worth. This 8bit/7bit barrier which RFC6152 mentions ever so lightly at the end of Section 3 is actually a pretty nasty thing if you think about it.