Yeah, I've been doing a lot of reading of standards while trying to hide all the messy details from users of the new API I've added to the email package.  I haven't gotten to smtplib yet :)

But, this stuff is messy.  If you want to understand a standard, you really have to read it, and lots of others standards besides, and then look at what various packages have chosen to implement, and figure out all the ways you think they did it wrong :)  As you have observed, implementations of SMTPUTF8 are scarce on the ground so far.

SMTPUTF8 may be about headers, but because the natural way of representing non-ascii headers in Python is as a (unicode) string, and SEND takes a single string (or bytes) argument, you can't separate dealing with the encoding of the headers from dealing with the encoding of the body unless you *parse* the payload as an email message so you can do the right thing with the body.  Thus you can't address adding SMTPUTF8 to smtplib without figuring out the API for the whole message, not just the headers.

So yes, the client can 'add Content-Type: text/plain; charset="utf-8"', but the process of doing that is exactly what I was talking about :)

Now, one option, as I said, it to put the burden on the application: it can check to see if SMTPUTF8 is available, and if so provide a DATA formatted with utf8 headers and charset='utf-8' bodies, and if it is not available, provide a DATA formatted with RFC2047 headers and charset="utf-8" bodies.  But I'd rather make smtplib (with the help of the email package) do the hard work, rather than have every application have to do it.  

Still, we could start with a patch that just makes it possible for an application to do it itself.  That would just need to accept non-ascii in the RCPT etc commands, pass it through as utf8 if SMTPUTF8 is available, and raise an error otherwise.

You are correct that the more convenient API I'm talking about also needs to be enhanced to provide a way to specify the alternate ASCII-only address.  I'd forgotten about that detail.  That's going to be very annoying from a clean-API point of view :(

And yes, it should raise an exception if SMTPUTF8 is not available and no ascii address was provided.