Opened 19 years ago
Closed 18 years ago
#3985 closed (fixed)
send_mail user-defined headers
| Reported by: | ido | Owned by: | Adrian Holovaty | 
|---|---|---|---|
| Component: | Core (Mail) | Version: | dev | 
| Severity: | Keywords: | custom headers | |
| Cc: | Triage Stage: | Accepted | |
| Has patch: | yes | Needs documentation: | no | 
| Needs tests: | no | Patch needs improvement: | yes | 
| Easy pickings: | no | UI/UX: | no | 
Description
How do send_mail, send_mass_mail, etc. permit one to define custom headers (such as for S/MIME, List-Id, etc.) in the outgoing email message?
This is a critical component of sending email that should not be overlooked in these docs.
Attachments (3)
Change History (8)
by , 19 years ago
| Attachment: | mail-additional_headers.diff added | 
|---|
comment:1 by , 19 years ago
I'm using django with this, 'mail-additional_headers.diff' patch to be able to pass additional headers to the mails.
import django.core.mail as mailer
(...)
hdict = {"Reply-To": reply_to_addr, 'List-ID': list_id}
mailer.send_mail(sbj, msg, from, recipient_list, additional_headers_dict=hdict)
I know that this is a very dirty way to do this but at least it works for me and not breaks anything. Also IMHO, mail.py should be redesigned from scratch.
I just wanted to share,
Thanks.
comment:2 by , 19 years ago
| Has patch: | set | 
|---|---|
| Summary: | what about user-defined headers? → send_mail user-defined headers | 
| Triage Stage: | Unreviewed → Design decision needed | 
comment:3 by , 19 years ago
| Patch needs improvement: | set | 
|---|---|
| Triage Stage: | Design decision needed → Accepted | 
A low priority change (after all, you have access to all of Python's mail infrastructure if you want it), but may be worth adding. I'm probably about +0.5 on this.
The patch needs improvement, though. There must be a less messy way to write the change at line 88.
by , 19 years ago
| Attachment: | mail-additional_headers.3.diff added | 
|---|
backwards compatibility and documentation
comment:4 by , 18 years ago
Would there be any interest in renaming additional_headers_dict to something shorter? It's a little verbose. Perhaps something like extra_headers?
comment:5 by , 18 years ago
| Resolution: | → fixed | 
|---|---|
| Status: | new → closed | 
work also with additional headers if there is any..