This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author r.david.murray
Recipients Allison.Vollmann, barry, ccgus, exarkun, giampaolo.rodola, pitrou, r.david.murray
Date 2010-11-05.09:07:33
SpamBayes Score 0.0
Marked as misclassified No
Message-id <1288948061.88.0.822892450886.issue10321@psf.upfronthosting.co.za>
In-reply-to
Content
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 issue 8050 and issue 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.
History
Date User Action Args
2010-11-05 09:07:42r.david.murraysetrecipients: + r.david.murray, barry, exarkun, pitrou, giampaolo.rodola, ccgus, Allison.Vollmann
2010-11-05 09:07:41r.david.murraysetmessageid: <1288948061.88.0.822892450886.issue10321@psf.upfronthosting.co.za>
2010-11-05 09:07:40r.david.murraylinkissue10321 messages
2010-11-05 09:07:38r.david.murraycreate