I'm getting an extra space in the mail subject when the subject has many characters. One such instance is when receiving the password reset email. It ends up being "Subject: Replacement login information for Some User Name at Some Long Site Name ((two spaces here)Secondary Name Here)".
I traced the extra space in the subject to mimemail.module where drupal_html_to_text is run. I then traced the point where the extra space was being introduced and it is in drupal/includes/mail.inc in function _drupal_wrap_mail_line. As the subject is longer than the 77 characters for the wordwrap call, two extra spaces and a newline are added as a string break character. As it is necessary to rewrite any HTML that might happen to end up in the subject (see: #369983: Plain text Email subject shows & as _amp; and " as _quot; ), the drupal_html_to_text call can't be eliminated.
It seems to me from #438058: Remove line feeds in subject that people were experiencing mail client breakage from the subject newlines, even though RFC 2822 says they should be OK. To fix this, the str_replace call was then added to remove the newlines.
An extra space would still exist in long subjects even after the str_replace. A quick fix is to replace in the mimemail.module for mimemail_prepare_message:
$subject = str_replace("\n", '', trim(drupal_html_to_text($subject)));
with:
$subject = str_replace("\n", '', str_replace(" \n", '', trim(drupal_html_to_text($subject))));
I'm not sure if this has any undesirable side-effects, however. Obviously my change could be refactored to look better as well. After the change, my email subjects look like they should without the extra space.
Comment | File | Size | Author |
---|---|---|---|
#1 | mimemail-1605230-1.patch | 634 bytes | sgabe |
Comments
Comment #1
sgabe CreditAttribution: sgabe commentedThere is no need to call str_replace twice, since we can use an array to designate multiple needles. Please test the attached patch and report back.
Comment #2
sgabe CreditAttribution: sgabe commentedCommitted to both branches.
Comment #3.0
(not verified) CreditAttribution: commentedAdded result of change to post.
Comment #4
ekidman CreditAttribution: ekidman commentedJust wanted to add to this issue, as I was having a related issue, and am using the newest version of MIME Mail. I too was getting extra spaces in my mail subjects whenever there were more than 60 characters. I traced this back to mimemail.inc and the mimemail_rfc_headers function (line 21). The original code was :
In order to fix the extra spaces issue, I took the extra spaces after the $crlf out. The new code is:
And appears to fix my issue of random spaces (4 of them in a row) appearing in my long email subjects. If there are any consequences of doing this, please let me know, but it seems to work great.
Comment #5
sgabe CreditAttribution: sgabe commented@ekidman Since this was a specific issue which has been fixed by a patch, please post your findings in the recently reopened #380334: Extra space in Subject and Reply-to headers, thank you!
Comment #6
cedders CreditAttribution: cedders commentedI'd like to reopen this as I think mimemail-1605230-1.patch can break Subject lines by condensing necessary spaces, and run together words is worse than an extra space. The subject line I see the header is
Subject: [Press Release] Wordwordwo wo w wordwor wordwo wo wordword, word xxxxxxxxxxxyyyyyy
where xxxxxxxxxxx yyyyyy and were two separate words in the newsletter title. Note that it didn't wrap at all when it's over 90 characters.
Firstly, I think the correct solution to multiple spaces may be to apply something like mimemail_rfc_headers(), which is intended to condense white space before wrapping, to $subject. This would also ensure the Subject line is wrapped at less than 78 characters as recommended in RFC 5322.
The short-term fix to the problem I saw is probably to remove " \n" from the array.
$subject = str_replace(array(" \n", "\n"), '', trim(drupal_html_to_text($subject)));
(edited as mimemail_rfc_headers() does not apply to $subject parameter.)
Comment #7
sgabe CreditAttribution: sgabe commentedThe development version does not include " \n", see in the repository.
Comment #8
sgabe CreditAttribution: sgabe commentedClosing due to no response, it may be invalid by now.