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.

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").

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.

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.

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....

(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.