The attached patch adds support to smtplib.SMTP.sendmail for the 'msg' argument to be, in addition to the currently accepted ASCII-only string, either a bytes string or a Message object. It also adds support for byte strings to smtplib.SMPT.data.

Binary support is straightforward: if a byte string is passed, it is subject to leading '.' quoting but otherwise transmitted as is (that is, no \r\n transformation is done, unlike the string case).

For Message object support, the Message is serialized via BytesGenerator, meaning that a message parsed from a bytes source can be successfully re-transmitted via smtplib. In addition to_addrs and from_addr can be set to None, in which case the addresses are obtained from the appropriate Message object headers (and, for safety, any Bcc header is deleted).

Although this patch is complete with docs, I'm not convinced this is the correct API.

First is the question of whether or not Message object support should be added. It is in the patch because I started the work with the idea that serializing a Message via BytesGenerator was the "right way" to get binary data into smtplib, but as the implementation fell out I in fact ended up adding support for arbitrary binary data to sendmail (and data). So in fact the Message object handling is not required in smtplib.

The feature is, however, clearly useful. Perhaps, however, it should live in email as one or more helper methods instead. I prefer having it in smtplib, but would like the opinions of others.

The second question is whether or not either functionality should be added to the existing sendmail method, or whether new methods should be created instead. The alternative API might be:

    send_bytes(from_addr, to_addrs, msg, mail_options, rcpt_options)
    send_message(msg, mail_options, rcpt_options, from_addr=None, to_addrs=None)

Having completed the patch I'm neutral on this API refactoring, and again welcome other opinions. 'send_bytes' doesn't really seem like the right name, since it implies sending arbitrary bytes when in fact what is happening is a complete message transaction. 'send_bytesmail'? Ugly :(

(See also bpo-8050 and bpo-4403.)

Note that I'd like to get some variation of this in (that at a minimum at least supports passing binary data to sendmail) before beta1, since it is the logical compliment to the new bytes support in the email package.

New patch that takes a middle ground on the API: sendmail accepts string and bytes, and a new method send_message accepts a Message object with a more convenient signature. I think send_message does belong in smtplib since it would be awkward and unintuitive to put the helper function in email, since one needs to create an SMTP server to call sendmail.

I am satisfied with this version; the delta against the existing code and docs is smaller and the API feels clean.

The new patch also updates a couple of the email package examples that use sendmail to use send_message (one of the sendmail examples is left untouched).

If there are no objections I'll commit this this weekend sometime.

One more patch update. This one includes the versionadded/version changed and a minimal What's New entry.

Committed in r86327.