Issue #354: Recognize 'Cc' and 'Bcc' in send_email()
|Reported by:||Ross Thomas|
|Created on:||2020-01-28 18:38|
|Updated on:||2020-01-29 18:06|
Is it possible to keep an empty recipients list in send_email() if ‘Bcc’ and/or ‘Cc’ headers are present?
I have a pushhook that tries to send anonymized bulk email (i.e. empty recipients with a ‘Bcc' header(*)) to all the followers of a repo (except the pusher, if present) in order to reduce the number of emails I need to send and to stop address leakage.
Currently, if the recipients list is empty or None the email is sent to all the admins as well as the ‘Bcc’ recipients, which is not really what I want. So I am reduced to looping through the recipients and sending an email per recipient.
I know I could have a spam-able dummy address as a placeholder in the recipients but that seems a little … cheesy.
Kallithea version: 0.5.1 (also in 0.5.0)
* I’m not sure if this is a standard lib restriction but one should also be able to specify multiple headers of the same name. I know that smtplib supports it but there seems to be several layers between here and there.
Comment by Ross Thomas, on 2020-01-28 18:47
Comment by Mads Kiilerich, on 2020-01-29 11:46
The odd adding of admins happen in https://kallithea-scm.org/repos/kallithea/files/0.5.1/kallithea/lib/celerylib/tasks.py#L261 . I don’t like how it just use admins. I think it would be better if it used a configured address. But it should perhaps also generally differentiate between “no-reply” messages and other messages where replies or bounces perhaps should be seen by an admin.
You can perhaps work around the addition of admins as sender by using the “null” address
<> that the mail RFCs use for slightly different purposes.
When migrating to py3, I tried to get rid of “rcmail” (but ended up with a less intrusive change for now).
I got as far as https://kallithea-scm.org/repos/kallithea-incoming/changeset/8d4fd33499e7ea431a8a7fdfbd7e86ac6b3869e8 .
Perhaps try to use smtplib directly (and help us to do the same and get rid of rcmail)
The internal functions were not really intended to be useful in other contexts. I don’t know if it would be a good idea to change them just for use in custom scripting. But perfect if we can clean up things and make it better for both internal and external use cases.
Comment by Ross Thomas, on 2020-01-29 18:06
I’ve tried to use the KT ops as much as possible and by using send_email() I was insulated from any underlying changes wrt config and/or lib usage.
I’ll try the null address approach (even though that is meant to be used on the ‘From’ side). But if it makes it into the envelope as a recipient it will fail.
As I mentioned, I have a work-around (inefficient as it is) for now. And it looks like you have already made a start on migrating to a 'better way'.
If I get some time after this BB migration I’ll take a closer, more leisurely look at the smtp support to see if I’m able to contribute in any way.