Long email subject headers have tab character inserted

Workaround for tab insertion in long email subject lines

Perhaps adding some comments about the workaround might help. :)

Updated, slightly cleaner, workaround for tabs in email subject headers

The workaround is to always use the email Header class to create the subject header for an email. The current code only does this if the header is non-ascii, otherwise, a string is used. The patch addresses this case.

When using a string a long subject line is folded with tabs. In (recent versions?) of Outlook the tabs are removed resulting in abutted words. In (recent versions?) of Tbird the tabs are rendered giving "wide" spaces between words. When using the header class, however, folding is done with a space and you seem to get the subject line looking as you'd expect.

If you read the discussions referenced above it seems the email stdlib is a bit broken. This patch just takes advantage of, what I think is, the happy accident that using the Header class seems to give the expected results (or, at least, better results than having tabs inserted in your subject line).

Looks good to me.

I'm afraid I don't see how this patch helps. forbid_multi_line_headers() is only invoked as part of SafeMIMEText and SafeMIMEMultipart. SafeMIMEText is used on the message and on each attachment; SafeMIMEMultipart is used on the message of a multipart email. The subject of an email is assigned to the EmailMessage? verbatim on line 219, and then put in the to message header verbatim on line 244. As far as I can make out, neither of these wrappers are used during subject handling.

A regression test case would be very helpful (regressiontests/mail would be the obvious location).

updated patch for compatibility with latest code and added test

I updated that patch and added a test to regressionstest/mail to show the problem.

The message method of EmailMessage? creates an instance of SafeMIMEText which overrides the default setitem of MIMEText to always invoke forbid_multi_line_headers on header assignment. So, at line 244 (247 patched), the assignment of the subject will cause forbid_multi_line_headers() to be called and the patch will ensure that an ascii subject header is returned as an instance of the Header class instead of a unicode string. This, in turn, ensures that a space, not a tab, is used as the continuation character if the subject line is long and has to be folded over several lines (this is what the added test checks for).

Prefering a space over a tab means that Outlook and Thunderbird will show a long email subject correctly.

Wrote a quick test app to confirm this issue. Raw email headers were as follows:

Before Patch:

...
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: This is a really long subject and I just wanted to test to see how
	this turned out in my email application. For some reason,
	tabs are inserted to fold the subject but we want spaces instead....
	don't we now?!
...

After Patch:

...
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: This is a really long subject and I just wanted to test to see how this
 turned out in my email application. For some reason,
 tabs are inserted to fold the subject but we want spaces instead.... don't
 we now?!
...

Also ran the regression test in the patch, which function as expected. I think this is ready for checkin

(In [8483]) Fixed #7747: Altered EmailMessage? such that messages with long subject lines don't use tabs in their continutation sequence. Tabs in subjects cause problems with Outlook and Thunderbird. Thanks to Mark Allison <mark.allison@maplecroft.com> for the report and fix.