Code

Opened 6 years ago

Closed 4 years ago

Last modified 4 years ago

#6918 closed (fixed)

Cannot set encoding of mail headers, only of message body

Reported by: Grzegorz Lukasik <hauserx@…> Owned by: serialx
Component: Core (Mail) Version: master
Severity: Keywords: encoding mail headers
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

In http://code.djangoproject.com/changeset/5553 support for encoding of mail body was added. I think also mail headers should be encoded with the same encoding, there is no way of setting mail headers encoding other than setting DEFAULT_CHARSET encoding right now - and for mail attachments as well.

For me it is a problem, because I need to set the encoding to other than utf-8, but I cannot do it for the mail subject.

Attachments (3)

mail_patch.diff (3.9 KB) - added by serialx 6 years ago.
mail-header-encoding.diff (6.8 KB) - added by serialx 6 years ago.
New improved working patch. (It actually changes the encoding of the mail header)
emailmessage-header-encoding.diff (5.4 KB) - added by oyvind 4 years ago.
New patch for r12398

Download all attachments as: .zip

Change History (12)

comment:1 Changed 6 years ago by serialx

  • Needs documentation unset
  • Needs tests unset
  • Owner changed from nobody to serialx
  • Patch needs improvement unset
  • Status changed from new to assigned
  • Triage Stage changed from Unreviewed to Accepted

Since the send_mail function API is frozen, adding another 'encoding' parameter may not be added. I'm submitting a patch to resolve this issue with two possible ways:

  1. Add 'encoding' parameter to the send_mail function.
  2. Add 'encoding' parameter to the EmailMessage constructor.

It _IS_ currently possible to specify the encoding of the mail using the EmailMessage like..

connection = SMTPConnection(username=auth_user, password=auth_password, fail_silently=fail_silently)
email = EmailMessage(subject, message, from_email, recipient_list, connection=connection)
email.encoding = 'utf8'
email.send()

But it does not kill to support encoding parameter in the send_mail and the constructor.

This patch enables..

connection = SMTPConnection(username=auth_user, password=auth_password, fail_silently=fail_silently)
email = EmailMessage(subject, message, from_email, recipient_list, connection=connection, encoding='utf8').send()

Or even

send_mail('Subject here', 'Here is the message.', 'from@example.com',
    ['to@example.com'], fail_silently=False, encoding='utf8')

Changed 6 years ago by serialx

comment:2 Changed 6 years ago by serialx

  • Has patch set
  • Triage Stage changed from Accepted to Ready for checkin

Marking ready for checkin. Can someone review my patch? Thanks.

comment:3 Changed 6 years ago by mtredinnick

  • Triage Stage changed from Ready for checkin to Design decision needed

It's not immediately clear this is a good idea. If you're passing text to Django it should be UTF-8 or Unicode as a rule. We allow different encodings in mail bodies because that allows slightly reduced data volume for East Asian languages. There's not really such a saving for mail headers.

Moving to "design decision needed", because this needs some thought (also patches requiring review are not "ready for checkin").

comment:4 Changed 6 years ago by serialx

It's not a problem about size. There are even some mail clients in the world that does not accept utf-8 title headers. (Asian countries old e-mail clients often do that) And apart from that, it's the user's choice to select different header encoding. Not ours. And we should give as many choices possible to user as possible.

comment:5 Changed 6 years ago by Grzegorz Lukasik <hauserx@…>

As serialx mentioned, the problem was not with the size of the message but with an email client - if I remember correctly it was interia.pl web server, which did not recognize UTF-8 encoding. So I was forced to use ISO-8859-2 encoding which is properly understood by all polish mail clients. And I was forced to use it not only in the body of the message but also in the Subject header.

Changed 6 years ago by serialx

New improved working patch. (It actually changes the encoding of the mail header)

Changed 4 years ago by oyvind

New patch for r12398

comment:6 Changed 4 years ago by kmtracey

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [12683]) Fixed #6918, #12791: If an email message has an encoding, actually use that encoding to encode body and headers. Thanks for patch with tests oyvind.

comment:7 Changed 4 years ago by kmtracey

  • Resolution fixed deleted
  • Status changed from closed to reopened

Test is causing a failure on the buildbots: http://buildbot.djangoproject.com/waterfall

Near as I can tell the only significant difference in the output is that the test is expecting the multipart message to start:

Content-Type: multipart/alternative; boundary=

But instead is getting:

Content-Type: multipart/alternative;\n\tboundary=

Buildbots are ubutntu, running Pythons 2.4, 2.5, 2.6. Oddly enough the test worked on my Ubuntu (older) using Python 2.5. Any clue what's causing this? I suppose we can just change the test to not care whether multipart-alternative; is followed by \n\t or not, since what we are really testing for is that the correct encoding has been used in the content....

comment:8 Changed 4 years ago by kmtracey

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [12688]) Fixed #6918: Adjusted the test in r12683 to more specifically look for what it is testing so it doesn't get thrown off by other minor differences in email ouput (hopefully). Also put a docstring back in its place.

comment:9 Changed 4 years ago by kmtracey

(In [12689]) [1.1.X] Fixed #6918, #12791: If an email message has an encoding, actually use that encoding to encode body and headers. Thanks for patch with tests oyvind.

Backport of r12683 and r12688 from trunk.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.