I've installed Drupal 4.7.3 and subscriptions.module.
Everything runs well, but when i have to receive notification of a comment for a blogq Drupal shows following message:

warning: mail(): Bad parameters to mail() function, mail not sent. in /www/horizonti.bg/www/root/drupal47/modules/user.module on line 410.

This message occurs only when the subject contains cyrillic letters.
The same problem occurs when drupal sends notification to the newly created user with cyrillic characters in the subject of the message.

Files: 
CommentFileSizeAuthor
#126 84883-126.patch856 bytesearnie
PASSED: [[SimpleTest]]: [MySQL] 46,456 pass(es).
[ View ]
#106 mime_header_encode-84883-106-D7.patch1.13 KBearnie
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mime_header_encode-84883-106-D7.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#106 mime_header_encode-84883-106-D6.patch1.12 KBearnie
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mime_header_encode-84883-106-D6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#105 mime_header_encode-84883-105.patch836 bytesearnie
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mime_header_encode-84883-105.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#95 remove_linefeeds_from_subject-84883-95-D6.patch966 bytespillarsdotnet
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch remove_linefeeds_from_subject-84883-95-D6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#95 remove_linefeeds_from_subject-84883-95.patch1.11 KBpillarsdotnet
PASSED: [[SimpleTest]]: [MySQL] 29,728 pass(es).
[ View ]
#87 84883_subject_newline_d7_4.patch797 bytesscor
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 84883_subject_newline_d7_4.patch.
[ View ]
#85 84883_subject_newline_d7_3.patch709 bytesscor
Failed: Failed to apply patch.
[ View ]
#77 84883_subject_newline_d7_2.patch860 bytesscor
Failed: Failed to apply patch.
[ View ]
#60 84883_subject_newline_d7_1.patch865 bytesscor
Failed: 9679 passes, 1 fail, 0 exceptions
[ View ]
#50 84883_subject_newline_2.patch848 bytesscor
Failed: Failed to apply patch.
[ View ]
#49 84883_subject_newline.patch1017 bytesgreggles
Failed: 7199 passes, 4 fails, 0 exceptions
[ View ]
#27 unicode.inc-chunkseparator.patch411 bytesximo
Test request sent.
[ View ]
#15 mail-error-screenshot.JPG73.52 KBnetbjarne
#9 workaround.JPG127.47 KBnetbjarne
#8 phpinfo.htm.txt45.7 KBnetbjarne
#7 shot-2-error.JPG116.69 KBnetbjarne
#6 shot-1-succes.JPG99.68 KBnetbjarne

Comments

What version of PHP are you using?

Title:warning: mail(): Bad parameters to mail() function, mail not sent. in /www/mysite.com/www/root/drupal47/modules/user.module onPHP Version 4.3.11

PHP Version 4.3.11

Title:PHP Version 4.3.11warning: mail(): Bad parameters to mail() function, mail not sent. in /www/mysite.com/www/root/drupal47/modules/user.module on

Sory! In the previous message I changed the title of the issue and couldn't restore it. But now the issue has the same title.

Oh man - just spend 6 hours on a day off to narrow this down.

I can confirm that there indeed is a bug somewhere.

Symptom:
If sitename in /admin/settings contains national characters, in my case "æ", mailing of login info etc from the user module fails with this error:

mail(): Bad parameters to mail() function, mail not sent. i /hsphere/local/home/oldrup/kegnaes-friskole.dk/modules/user.module på linje 430.

User.module version info:

// $Id: user.module,v 1.612.2.16 2006/08/02 18:13:27 killes Exp $

PHP Version: 4.4.4

Workaround:
Avoid using national characters in sitename. If I replace "æ" with "ae" in my sitename, the user module can once again email.

I can reproduce this error on several installations. Any help is greatly appreciated.

A small side note, the contact module has not got the same problems with national characters - I have been sending several messages using the contact module, which included "æøå" and such in the subject line - all went through fine.

Please let me know if I can provide any useful info to help get this fixed. I'd really like my site to have the correct name ;-)

StatusFileSize
new99.68 KB

Screenshots and phpinfo attachments for more details

StatusFileSize
new116.69 KB

Here the second screenshot where mailing fails due to national characters in sitename.

StatusFileSize
new45.7 KB

Lastly, phpinfo dump.

StatusFileSize
new127.47 KB

More diagnostic results and a better workaround.

I found out that BOTH the user.module AND the contact.module, uses the user_mail function from the user.module to send emails. The contact.module succeeds, the user.module fails - sending emails the email subject includes national characters.

The subject line of emails sent by the user.module, can be modified in the administer >> settings >> users menu. If having a sitename with national characters, you can replace every instance of %site in the text fields, with plain ascii instead.. Please see screenshot.

Following on netbjarne's work...

In contact.module we have this subject:

383 : dries 1.65 $subject = '['. variable_get('site_name', 'drupal') .'] '. $form_values['subject'];

In user.module we have a subject that depends on the reason it is being sent, but they all looks similar to this:

1513 : unconed 1.655 return t('Account details for !username at !site', $variables);

Note that I'm pasting from annotate view so we know which line/commit is involved.

So, it seems to me that by using different methods of variable insertion into the email subject we are getting this different behavior of the mail succeeding in one case and failing in another.

In both cases we use drupal_mail to send the messages. Perhaps some cleanup of the subject would be appropriate in there, but I'm not sure what kind of cleanup is necessary.

Title:warning: mail(): Bad parameters to mail() function, mail not sentwarning: mail(): Bad parameters to mail() function, mail not sent. in /www/mysite.com/www/root/drupal47/modules/user.module on
Version:5.x-dev» 4.7.3
Assigned:» Unassigned

Hi,
I have the same problem on a unix php 4.4.3 server. I recently migrated from php 4.4.1. which never caused this problem.
This problem occurs whenever the subject of the email sent by the server is longer than 46 characters and contains national characters. I also managed to get this message with contact module, when the subject of the email is long enough.
In the mime_header_encode function, when the subject of the email contains national characters, the subject is encoded in base64 by chunks of 47 characters. If there is only one chunk, there is no problem, the email is sent with the encoded subject. But if there are more than one chunk, a line break is put at the end of each chunk. I guess it's to comply with the RFC2047 :

An 'encoded-word' may not be more than 75 characters long, including
'charset', 'encoding', 'encoded-text', and delimiters. If it is
desirable to encode more text than will fit in an 'encoded-word' of
75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
be used.

Now, this is what the php mail function says about the subject of the email :

subject

Subject of the email to be sent.

Caution

This must not contain any newline characters, or the mail
may not be sent properly.

and it doesn't mention anything about the encoded subjects.

When I look at the source of some emails sent from a config which works (unix php 4.3.11) with a long subject with national characters, the line breaks of the subject have been deleted (by the mail function I assum). All the base64 chunks of the subject end up on the same line with a SPACE between each of them, so I figured there was no point to have the line break in the mime_header_encode function and decided to remove it.
The line break is added in unicode.inc, line 232:

      $output .= ' =?UTF-8?B?'. base64_encode($chunk) ."?=\n";

I deleted the "\n" and it worked. The only thing is that the email sent doesn't comply with the rfc2047 since all the chunks of the subjects are on the same line, but it was already like that before on the working config. Try to send a message with contact module with a long subject like this :
Le sujet de ce message est très long!
even drupal.org puts all the chunks on the same line!

I'm not sure what triggers this problem (version of php, mb_string settings) but check your config and post more details about it!

Version:4.7.3» 5.x-dev

moving to HEAD since user_mail hasn't changed. But apparently PHP has(?).

Version:5.x-dev» 4.7.x-dev

Steps attempted:
1. send a message on the sitewide contact with subject containing: på and æ.
2. set sitename to contain æ
3. send message on user personal contact form

Expected results:
Error messages

Actual results:
Mails went through, no errors printed to screen nor watchdog.

My tests were only on Drupal5.x head as of today, so I imagine this is Drupal4.7 related. If my means of testing were wrong or if someone else can confirm it in 5.x then please comment and change the version back to Drupal5.x.

Priority:Critical» Normal

I've tried to repro this on 4.7-x running on php 5.1 and couldn't reproduce it. Downgrading.

StatusFileSize
new73.52 KB

On my host, surftown, the problem still exists. Also in 5.0 beta 2 - see attached screenshot.

Needless to say, that if in the "request new password" text, replace !site (that contains national characters), with !uri (that only contains ascii), the problem goes away.. Same ol' I

Bjarne

Version:4.7.x-dev» 5.x-dev

So, I'd say this is a combination of national characters in the subject AND a certain configuration of PHP. I agree with Killes on priority, but move it back to 5.x since it affects that and should get attention there.

@netbjarne - the problem only affects the per user contact page, right? And since you are one of the few who can test this, would you be willing to try out a patch if one is provided?

This is really a bug in PHP that should be addressed. Removing the linebreak means disobeying the RFC.

I had the same problem that I solved with the solution above. I think this issue concerns only a few PHP configurations and is not related to the version of drupal. I'd say it's directly related to the mail function of PHP, and maybe to the national settings. The problem does not only appear in the contact page, but as I stated previously

This problem occurs whenever the subject of the email sent by the server is longer than 46 characters and contains national characters.

I first notice this problem with subscriptions.module which was not sending the emails to the users who had a username containing national characters... Try as an example to create an account with a long user name containing national characters. The subject of the resulting email has to be longer than 46 characters. This will force the subject of the email to be encoded and several chuncks will be generated... and the bug should appear... at least on the buggy PHP configurations.
Greggles, have you tried that? Does the encoded email subject in the email header contain any line break ?
I can also try a patch if provided.
Steven, I agree that the RFC is disobeyed, but shouldn't it be PHP that should add these linebreaks instead, since the PHP documentation requires no linebreak in the email subject ?

PHP should not be adding the linebreaks, unless PHP were to actually accept a random unicode string and do the encoding itself.

PHP requires us to do the encoding, and separating chunks on lines is an essential part of this.

This is what the php mail function says about the subject of the email :

subject

Subject of the email to be sent.

Caution

This must not contain any newline characters, or the mail
may not be sent properly.

and it doesn't mention anything about the linebreaks in the case of an encoded subject.
Is there an exception for the encoded subjects ?

Moreover, when I send a message through drupal.org, the encoded subject chunks are all on the same line:

Subject: =?UTF-8?B?W2RydXBhbC5vcmddIHTDqXN0IHBvdXIgdm9pciBzaSBsZXMgc3VqZXQgcGxhbnQ=?=  =?UTF-8?B?ZW50IGNoZXogZHJ1cGFsLm8=?=

More info on this bug.

I wrote messages on the contact form. Some went through. Some didn't. I can confirm, that subject messages have to be of a certain lengt (46 has been mentioned, that looks about right) - AND that national characters must be present in the final subject of the email (for instance, if the sitename contains them).

Heres the subject of a message that passed through the user_mail function:
[Kegnæs Friskole] 0123456789012345678901234567

Add another "8" to the subject, and the mail fails.

I will try the hack of removing newline characters of in the subject, and return with additional info.

Bjarne

I found me another workaround (gotta make a list of drupal workarounds, it gets hard to remember to re-apply them all every time a new version is installed ;-))

in include.inc, the mime_header_encode function, i replaced

    $chunk_size = 47; // floor((75 - strlen("=?UTF-8?B??=")) * 0.75);

with
    $chunk_size = 400; // floor((75 - strlen("=?UTF-8?B??=")) * 0.75);

Its an overly big chunk size, since the mail form does not allow lengthy subjects, however, utf-8 encoding seems to lengthen things a low...

Now - mail passes through just fine - no linebreaks in the subject (who came up with that idea anyway) - and no lost messages.

Bjarne

Mistake in last post. The edited file was not include.inc, but unicode.inc. Sorry..

I had the similar problem, but "$chunk_size = 400;" solved it. Many thanks to netbjarne!

What's the story on this bug? Has it been fixed in another issue, or is this bug still hanging around? This should be fixed for Drupal 6.

I just got this error without having any national characters in the subject line. I was creating a new user from admin/user/user/create, and the subject of the email message to be sent out was En konto har blitt opprettet for deg på !site where !site = Wannabe. I tried some of the mentioned workarounds, but found simply removing the \n</codefrom the end of <code>$output .= ' =?UTF-8?B?'. base64_encode($chunk) ."?=\n"; did the trick. Why is the newline there in the first place? It's looks like it's the newline that breaks the mail() function.

I'm not sure why I got this error when I had no national characters in the subject line or the site name. This was on Drupal 5.1, PHP 4.4.6, Apache/1.3.37 (Unix).

StatusFileSize
new411 bytes
Test request sent.
[ View ]

I'm obviously blind, I did have an å in the subject line!

I looked into the background of this issue, and found these links:
http://www.php-security.org/MOPB/MOPB-34-2007.html
http://bugs.php.net/bug.php?id=15841

Didn't make me any wiser though..

Then I saw this note in the mime_header_encode() function_

* - Using \n as the chunk separator may cause problems on some systems and may
*   have to be changed to \r\n or \r.

Changing \n to \r did the trick, Drupal could now send the mail with a subject containing å. I know this doesn't follow the RFC, but it works with the mail() function and I believe that's more important. Having to manually change this deep inside the core shouldn't be necessary, why can't the chunk separator be \r by default? See the attached patch.

Perhaps the following would take care of the issue? I don't have a good scenario to test with.

-      $output .= ' =?UTF-8?B?'. base64_encode($chunk) ."?=\n";
+      $output .= ' =?UTF-8?B?'. base64_encode($chunk) .utf8_encode("?=\n");

Title:warning: mail(): Bad parameters to mail() function, mail not sent. in /www/mysite.com/www/root/drupal47/modules/user.module onwarning: mail(): Bad parameters to mail() function, mail not sent
Version:5.x-dev» 5.2
Assigned:Unassigned»
Priority:Normal» Critical

warning: mail(): Bad parameters to mail() function, mail not sent. in /home/content/p/u/r/purihostsiam/html/includes/common.inc on line 1979.

this message occurs when create a new account . somebody help me please!.

siammoney.net: are you using accented characters in your username when creating your account?

Component:user.module» aggregator.module

yes I have test create a new account for quest by use accented characters in username

Version:5.2» 5.x-dev
Component:aggregator.module» user.module

aggregator???
can you check that you don't have the problem with non accented chars.

@ximo: whether you use \r, anything else or nothing at all, it's the same as long as it's not \n (see #11)

thank you, but when I use a common chars such as puri007 that always show this errors.How 's about syntax in line 1976 on common.inc? I confuse in $mimeheaders and $subject.

thank you for suggestion,I try new install drupal 5.2 that good work.I think it 's cloud be errors about theme or module that after install. so happy

a simple username like puri007 should not give you any error. did you modify the code of the core? I suggest you install a fresh drupal-5.3 on the same server without any contributed module to see if you still get the error when creating an account with puri007.

thank you, I use to drupal-5.2 because it's no error after new install.Now,I have suspect to log in of drupal members why accept a cookies because another's website had not to opened the cookie.

Title:warning: mail(): Bad parameters to mail() function, mail not sent. in /www/mysite.com/www/root/drupal47/modules/user.module onwarning: mail(): Bad parameters to mail() function, mail not sent
Version:4.7.3» 5.2
Assigned:Unassigned»
Status:Active» Postponed (maintainer needs more info)

Please reopen when this has been tested with a current version of 5.x. 5.2 is now an older release.

I'm having the same issue with D6.1. my site phsite.org/main is using an Arabic name in it's site name, I tried to change !site by explicitly defining it but that didn't help :(
I used to overcome this with the smtp.module, but it is not ported to 6.x yet, not sure if it even will be ported!

Server PHP version is 4.4.6

Version:5.2» 6.x-dev
Assigned:» Unassigned
Priority:Critical» Normal

I'm still having the same issue, does any one know of a solution?

@liquid crystal: can you try the fix I described in #11 http://drupal.org/node/84883#comment-449438
it's not ideal, but it might help you. please report whether it works for you or not.
also, how many characters does the subject of the email contain?

Hi scor,

It seems Drupal 6 is a lot different than Drupal 5 in terms of the unicode.inc. I'm not a programmer by any mean but at least that how it looks to my eyes:

279 function mime_header_encode($string) {
280 if (preg_match('/[^\x20-\x7E]/', $string)) {
281 $chunk_size = 47; // floor((75 - strlen("=?UTF-8?B??=")) * 0.75);
282 $len = strlen($string);
283 $output = '';
284 while ($len > 0) {
285 $chunk = drupal_truncate_bytes($string, $chunk_size);
286 $output .= ' =?UTF-8?B?'. base64_encode($chunk) ."?=\n"; <--- should I remove this \n?
287 $c = strlen($chunk);
288 $string = substr($string, $c);
289 $len -= $c;
290 }
291 return trim($output);
292 }
293 return $string;
294 }

The subject is 69 characters long, do you think I should try and make it less than 64?

Hi scor,

Removing the \n from that line solved the problem, thanks a zillion time :D

I've solved the problem on v6.2, PHP 4.4.7 in the following way:

in file 'includes/mail.inc', in line 186 replaced

mime_header_encode($message['subject']),
with
str_replace("\n", ' ', mime_header_encode($message['subject']) ),

It just replaces LF with SPACE in the subject after it is received from the mime_header_encode.

Component:user.module» base system
Status:Postponed (maintainer needs more info)» Needs work

This problem is encountered by all modules that send e-mail, including the contact module.

In the print module, a user was unable to send a message with the subject:
"admin has sent you a message from Urduseek.com انگریزی اردو لغت"

He later tried the same in the contact module, and it also failed. However, I have tried it in my system and it works fine.. He tried it in another system and was it was also fine.. The original print module issue is : #290517: bad parameters in mail() function.

João

I encountered this error in a site which is hosted by Godaddy. I have solved this error by using SMTP Module: http://drupal.org/project/smtp.

Version:6.x-dev» 7.x-dev
Status:Needs work» Active

There is no patch so setting back to active. Also bumping to 7.x since the problem still exists. Should we consider that Drupal core should use the logic from smtp module?

Status:Active» Needs work

There is a patch (in #44). It's not a machine-readable patch to use with the patch program, but it is a patch anyway.

João

Status:Needs work» Needs review
StatusFileSize
new1017 bytes
Failed: 7199 passes, 4 fails, 0 exceptions
[ View ]

Which makes it not a patch. We only set the status to patch (code needs review) when there is a machine readable patch.

This patch was rolled against 6.x but also applies to 7.x.

StatusFileSize
new848 bytes
Failed: Failed to apply patch.
[ View ]

note that this breaks the RFC2047, but seems to be the only way to fix the problem, unless it is fixed on a PHP level (as suggested by Steven).
patch documented.

The patch looks pretty. I don't have a means to test it though.

Status:Needs review» Needs work

The last submitted patch failed testing.

This worked for me :-)

Thanks

Status:Needs work» Needs review

Resetting for the testbot one more time.

Status:Needs review» Reviewed & tested by the community

Status:Reviewed & tested by the community» Needs work

Instead of writing 'see #84883', please reference the correct article in the RFC. Thanks.

Title:warning: mail(): Bad parameters to mail() function, mail not sentBad parameters to mail()

so far this issue has not been reproduced on PHP 5 so it might NOT be necessary to commit it to HEAD (and just to 6.x and 5.x). I'll try to reproduce on PHP 5.
EDIT: missed the NOT

I tried to send an email from Drupal 6 installed in a local web site using PHP5, but I didn't have any problems. I changed the user name to Espero ååå, and then I sent a message using the contact form; Drupal didn't return any error messages.

I must then say that the local web site is running on a Mac using Mac OS X 10.5.6.

Status:Needs work» Needs review
StatusFileSize
new865 bytes
Failed: 9679 passes, 1 fail, 0 exceptions
[ View ]

rerolling patch against HEAD with link to this issue. I wasn't able to reproduce the issue on PHP 5, therefore I'm not convinced this needs to go into HEAD.
Would this issue deserve a test?

@Kiam@avpnet.org: the subject of your email must be at least 46 character long to reproduce the error. Try with the following subject:

Le sujet de ce message est très très très long!

I tried it, and it didn't receive any error message.
I also tried it on Drupal 6.9 on my web site, running on Apache/1.3.41 (Unix) with PHP 5.2.6; the result didn't change.

It seems the problem is not present in PHP5.

I still have the same problem on Drupal 6.9 PHP 5.2.6 when I send mail through the printmail functionality of Printer-friendly pages module.
Please try it here:
http://yousef.raffah.com/printmail/node

Anybody else is still affected by this problem except me? :(

Status:Needs review» Fixed

Hi,

I have just used Drupal 5.15 to send a mail with subject "Le sujet de ce message est très très très long!Le sujet de ce message est très très très long!Le sujet de ce message est très très très long!" (3x the subject in #61) and it made it across OK..

I was using the print_mail module to send the message. I do notice that the contents of the message arrive as:

Subject: =?UTF-8?B?TGUgc3VqZXQgZGUgY2UgbWVzc2FnZSBlc3QgdHLDqHMgdHLDqHMgdHLDqHMgbG8=?=  =?UTF-8?B?bmchTGUgc3VqZXQgZGUgY2UgbWVzc2FnZSBlc3QgdHLDqHMgdHLDqHMgdHLDqHM=?=  =?UTF-8?B?IGxvbmchTGUgc3VqZXQgZGUgY2UgbWVzc2FnZSBlc3QgdHLDqHMgdHI=?=
MIME-Version: 1.0
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8Bit
X-Mailer: Drupal
Errors-To: me@example.com
Sender: me@example.com
Reply-To: =?UTF-8?B?Ikpvw6NvIENhcmxvcyA1ZWdyw6NvIFZlbnR1cmEgYSB2ZXIgc2UgaXN0byBkw6E=?=@example.com,
  =?UTF-8?B?IHByb2JsZW1hcyIgPGpjbnZABB12LmVzPg==?=@example.com
From: =?UTF-8?B?Ikpvw6NvIENhcmxvcyA1ZWdyw6NvIFZlbnR1cmEgYSB2ZXIgc2UgaXN0byBkw6E=?=@example.com,
  =?UTF-8?B?IHByb2JsZW1hcyIgPGpjbnZABB12LmVzPg==?=@example.com

Anyway, if this seems to with both Drupal 5.15 and Drupal 6.9 (both on PHP5), and it didn't work with another Drupal 6.9 in PHP5, it must be something outside of Drupal.. I am moving this to fixed status, unless liquid crystal can pinpoint the problem.

@liquid crystal: does applying this patch solve the problem for you??

João

Status:Fixed» Needs review

this is not fixed yet!

I just tried the patch in #60 and didn't get the error message I used to get earlier, however, I will still investigate further and report back if I stumbled upon any issue.
Thanks for the tip jcnventura

Status:Needs review» Needs work

The last submitted patch failed testing.

Any confirmation of #68?

Version:7.x-dev» 6.9

Languaje: Spanish, with letters like ñ á é í ó ú.

Drupal 6.9

PHP Version 5.2.6

The problem begins when I installed the es.po for Spanish. I think (?) before it works properly.

Now, even if I come back to English languaje the problems is there.

I can confirm: this issue happens to me when I installed the Spanish translation for drupal (es.po). Before it works properly.

I have solved this error by using SMTP Module: http://drupal.org/project/smtp.

See #46.

Version:6.9» 6.10

I'm on Drupal 6.10 using php 5.2.8 and the problem(s) described above apply to me too. (In case it matters, I also have this on the Status page: Unicode library PHP Mbstring Extension.)

Here is the issue. When the title of a node (book page) has "curly quotes" aka "smart quotes" in it, there is an error after submitting a comment to the page:

Unable to send e-mail. Please contact the site admin, if the problem persists.

Appears at the top of the page upon comment submission.

In the Recent Log entries (/admin/reports/dblog) there are two errors:

  • php error: mail() [function.mail]: Bad parameters to mail() function, mail not sent. in /html/includes/mail.inc on line 193.
  • mail error: Error sending e-mail (from Admin @ domain.org to Admin @ domain.org).

If I go in to the book page, and edit the title and put plain quotes in place of the curly quotes, the email is sent without an error.

Best I can tell, my specific issue is in /includes/mail.inc on line 186. But I don't know enough to know how to address the issue, except for the workaround of not using fancy quotes.

@hayworth and @Bairnsfather could you try with the patch at #60 and see if you still have the same problem?

Version:6.10» 6.12
Component:base system» language system

Same issue.
I've been looking at some transliteration implementation to replace those characters with either plain english or the html entities (preferred).
I'm new to drupal and not a php expert so any help would be appreciated.

I too had this issue. Patch in #60 did not work. Workaround in #22 works.

Using drupal 6.12, php 5.2.6.

StatusFileSize
new860 bytes
Failed: Failed to apply patch.
[ View ]

rerolling

I had the same problem. In my case it was solved by solution sugested in comment #22. (drupal 6.11 , php 5.2.5)

#22 + #23 works just fine and solves the problem

THANKS netbjarne!!!

Version:6.12» 6.13

One more thing. To debug this I changed mail.inc to send mails with a fixed subject of "test" and put the encoded subject in the body so I can see what's output by the function.

It is:
=?UTF-8?B?W9Ce0LHRidC90L7RgdGCINCW0LjQstC+0YLQstC+0YAg0L7RgiDQoNC+0LTQvg==?=
=?UTF-8?B?0LLQviDQodC10LvQuNGJ0LVdINGC0LXRgdGC0LLQsNC5INGC0L7QstCw?=

As you can see, the first encoded word is 76 characters long which is one more than what the RFC allows. I tried to reduce chunk to 39 and now encoded word is less than 70 characters but it doesn't help at all.

One more thing against the RFC is that multiple lines in the RFC are separated by CRLF and in mime_header_encode it is only \n

I can confirm that patch from #77 works for me:
godaddy linux hosting vs PHP 5.2.8 (ask if you need more details)
drupal 6.13

The issue that encoded_word is 76chars is still worrying me though.

Thanks!

Patch from #77 works also for me.

I uses Hebrew lang.,
hosting - GoDuddy.

Thanks!

Status:Needs work» Reviewed & tested by the community

#77 working fine.
Hosting: home.pl

Version:6.13» 7.x-dev
Status:Reviewed & tested by the community» Needs work

1. Bugfixes are first committed to Drupal 7 to ensure we do not introduce regressions.
2. Dries already asked above to reference the proper RFC instead of this issue in the comment.

Status:Needs work» Needs review
StatusFileSize
new709 bytes
Failed: Failed to apply patch.
[ View ]

rerolling just in case. The php mail function specs have changed and there is no such warning about the newlines in the subject anymore, and all it requires is to comply with RFC 2047. I'm tempted to close this issue except that some people have reported the same problem on PHP 5 (while I'm not able to reproduce it on my dev laptop). I'm leaving this open until they report back. Again, as a reminder, the problem occurs when the subject of the email is more than 46 characters and contains national characters like

Le sujet de ce message est très long!

Status:Needs review» Needs work

The last submitted patch failed testing.

Status:Needs work» Needs review
StatusFileSize
new797 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 84883_subject_newline_d7_4.patch.
[ View ]

I was working on an outdated mail.sending.inc

"$chunk_size = 400;" solved my problems :D

If this problem is not supposed to happen with modern versions of PHP, we should at least add a @todo.

Component:language system» mail system

I have a spanish site (6.14) n' had the same problem. "$chunk_size = 400;" worked for me!!! thanks netbjarne!!!

#87: 84883_subject_newline_d7_4.patch queued for re-testing.

Status:Needs review» Needs work

The last submitted patch, 84883_subject_newline_d7_4.patch, failed testing.

Version:7.x-dev» 6.20

$chunk_size (./includes/unicode.inc) to 400, solved my problem. PD: I got the spanish translation

Version:6.20» 7.x-dev
StatusFileSize
new1.11 KB
PASSED: [[SimpleTest]]: [MySQL] 29,728 pass(es).
[ View ]
new966 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch remove_linefeeds_from_subject-84883-95-D6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Re-rolled patch from #87.

Status:Needs work» Needs review

Patch at #95 [remove_linefeeds_from_subject-84883-95.patch] worked for me on godaddy hosting a non-english d7 site for user registration e-mails (contact form e-mails were working OK).

Tks @pillarsdotnet.

Version:7.x-dev» 8.x-dev
Assigned:Unassigned» pillarsdotnet
Issue tags:+needs backport to D6, +needs backport to D7

Bumping and tagging as per standards.

You can help this issue by posting a review:

  • Decide whether all code and comments comply with Drupal coding standards.

  • Decide whether any included tests are necessary and sufficient.

  • Decide whether the patch actually solves the problem. There should be a reproducible test where the current code fails and the patched code succeeds.

A review that affirms success in all of the above should also:

  • Change the issue status from "Needs Review" to "Reviewed and Tested By the Community".

Otherwise, the review should:

  • Explain what is wrong with the proposed patch and/or supply a corrections to it.

  • Change the issue status from "Needs Review" to "Needs Work".

Perhaps this issue is doomed to failure, since there has only been one patch against Drupal core mail system that ever became RTBC or fixed.

EDIT: Correction. There have been two. The other one is a four-year-old patch against D5.

It's a relatively new component for issues...

Title:Bad parameters to mail()Remove linefeeds from subject line to ensure that emails get sent properly.
Priority:Normal» Major

Better title.

Since this bug results in data loss (lost emails), does it qualify as "Major" ?

Title:Remove linefeeds from subject line to ensure that emails get sent properly.mime_header_encode doesn't correctly follow rfc2047.
Priority:Major» Normal
Status:Needs review» Needs work

The patch supplied will break subject lines longer than 75 characters since \r\n can be inserted. The problem is actually in mime_header_encode(), the appended \n to the chunks should be \r\n as per http://www.faqs.org/rfcs/rfc2047.html.

Status:Needs work» Needs review
StatusFileSize
new836 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mime_header_encode-84883-105.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

An 'encoded-word' may not be more than 75 characters long, including
'charset', 'encoding', 'encoded-text', and delimiters. If it is
desirable to encode more text than will fit in an 'encoded-word' of
75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may
be used.

The patch removed a comment concerning the chunk separator because I don't see any relevance to it. All systems compliant with rfc2047 must use CRLF SPACE as the chunk separator and since we use PHP mail() function it is a requirement to follow rfc2047. The patch in #27 was almost correct but didn't follow rfc2047 either.

StatusFileSize
new1.12 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mime_header_encode-84883-106-D6.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
new1.13 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch mime_header_encode-84883-106-D7.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Here is the same patch for D7 and D6.

Passing the torch to earnie. Somebody who has gained more respect than I (@sun? @Damien Tournoud? @Dave Reid?) should review the patch. Also, it should come with tests.

EDIT: Webchick says she'd accept an RTBC from scor. And instead of "gained more respect", I should have said "established a pattern of being really knowledgeable about this area of code."

Assigned:pillarsdotnet» Unassigned
Issue tags:+Needs tests

Add the test is a different issue and one I don't have time to do. The patch is simple and if the testing doesn't exist it should be handled separately IMO.

The usual practice for urgent fixes is that the fix is committed first, then the issue changes back to "needs work" while tests are added. I'd be willing to write tests myself, but first I want to see a review from someone who is qualified to get this thing approved. I'd mark this issue RTBC myself except that I'm absolutely sure that webchick would bump it back to "Needs review" with a note that a core developer should look it over.

"$chunk_size = 400;" worked for me too. Thanks so much

Version:8.x-dev» 6.22

mime_header_encode should not encode Content-type definition... even if there's CRLF.

Why?
multipart/mixed; can add CRLF for boundary definition.

Check: http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

Thanks!

Version:6.22» 8.x-dev

Please don't change the version.

This indicates that the entity consists of several parts, each itself with a structure that is syntactically identical to an RFC 822 message, except that the header area might be completely empty, and that the parts are each preceded by the line

--gc0p4Jq0M2Yt08jU534c0p

Note that the encapsulation boundary must occur at the beginning of a line, i.e., following a CRLF, and that that initial CRLF is considered to be part of the encapsulation boundary rather than part of the preceding part. The boundary must be followed immediately either by another CRLF and the header fields for the next part, or by two CRLFs, in which case there are no header fields for the next part (and it is therefore assumed to be of Content-Type text/plain).

NOTE: The CRLF preceding the encapsulation line is considered part of the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, should have two CRLFs preceding the encapsulation line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary.

The requirement that the encapsulation boundary begins with a CRLF implies that the body of a multipart entity must itself begin with a CRLF before the first encapsulation line -- that is, if the "preamble" area is not used, the entity headers must be followed by TWO CRLFs. This is indeed how such entities should be composed. A tolerant mail reading program, however, may interpret a body of type multipart that begins with an encapsulation line NOT initiated by a CRLF as also being an encapsulation boundary, but a compliant mail sending program must not generate such entities.

Encapsulation boundaries must not appear within the encapsulations, and must be no longer than 70 characters, not counting the two leading hyphens.

The encapsulation boundary following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter is identical to the previous delimiters, with the addition of two more hyphens at the end of the line:

--gc0p4Jq0M2Yt08jU534c0p--

I don't see this as having anything to do with the change purposed in #106 which has to do with encoding and not mixed/multipart. In fact the two can co-exist in the same email, i.e. I can encode a multipart part.

As stated in the definition of the Content-Transfer-Encoding field, no encoding other than "7bit", "8bit", or "binary" is permitted for entities of type "multipart". The multipart delimiters and header fields are always 7-bit ASCII in any case, and data within the body parts can be encoded on a part-by-part basis, with Content-Transfer-Encoding fields for each appropriate body part.

Title:mime_header_encode doesn't correctly follow rfc2047.mime_header_encode() doesn't correctly follow the RFC 2047

Status:Needs review» Needs work

The last submitted patch, mime_header_encode-84883-106-D6.patch, failed testing.

Status:Needs work» Needs review

This issue is 6 years old and getting older. The patch is simple. Should we bump to major just to get a few core maintainer eyes this way?

No, it would be better to provide a working patch first + tests + reviews from people that set it to RTBC.

Status:Needs review» Needs work

Status:Needs work» Needs review

The problem exists that the RFC 2047 is not followed. Per PHP documentation this is the RFC that they use. Therefore Drupal is broken.

Status:Needs review» Needs work

No patch for D8 here, so needs work.

"needs work" is used when a patch has not been provided, or when the current patch needs to be changed. In this case, there isn't a patch that applies for Drupal 8.
"needs review" would say to the users "there is something to review," which is not true as there isn't a patch that applies to the current Drupal version.

#105: mime_header_encode-84883-105.patch queued for re-testing.

StatusFileSize
new856 bytes
PASSED: [[SimpleTest]]: [MySQL] 46,456 pass(es).
[ View ]

Rerolled patch.

@earnie That proves my point: The test bot was not able to apply that patch; ergo, that patch needs to be re-written. "needs work" is the right status, in such case.
If somebody submitted a different patch, then "needs review" should be the correct status; differently, the test bot would not test the new patch.

Is this going to be ported to D7 ?

Status:Needs review» Needs work

We're going to need a test to prevent future regression, marking as "needs work". If you don't have time to write the test (totally understandable), then just describing how to test it would be very helpful. If it's simple enough, we might even be able to put a Novice tag on this and get a new test-writer to take a crack at it. The patch itself looks sane enough.

Status:Needs work» Needs review

Yes, I agree that we need a test but that can be a separate issue. This is a long standing bug that never had a test before and it needs to get fixed regardless of the testing. The RFC specification is clear and Drupal is not following it.

Issue tags:+Novice

Well, you can try for sure! :)

For the unit test: call mime_header_encode() and then verify the chunk size (45) and the line endings are \r\n instead of just \n. Does that sound about right?

Status:Needs review» Reviewed & tested by the community

I had a few issues related to this, and the patch fixed it for me. Thanks!
Tested on D6 and D7.

Status:Reviewed & tested by the community» Needs work

Yes this needs a test before it can go in per #130.

Note: for those that tried the patches in this issue and still have the 'bad parameter' error, you may want to see #300387: drupal_mail_send with long UTF-8 subject puts \n to subject line, the mail() function won't send it then..