warning: mail(): Bad parameters to mail() function, mail not sent

What version of PHP are you using?

PHP Version 4.3.11

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:

User.module version info:

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 ;-)

Screenshots and phpinfo attachments for more details

Attachment	Size
shot-1-succes.JPG	99.68 KB

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

Attachment	Size
shot-2-error.JPG	116.69 KB

Lastly, phpinfo dump.

Attachment	Size
phpinfo.htm.txt	45.7 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.

Attachment	Size
workaround.JPG	127.47 KB

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.

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:

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!

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

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.

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

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

Attachment	Size
mail-error-screenshot.JPG	73.52 KB

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:

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

with

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

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_

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.

Attachment	Size
unicode.inc-chunkseparator.patch	411 bytes

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

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?

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

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.

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

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.

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.

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?

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

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.

Attachment	Size
84883_subject_newline.patch	1017 bytes

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.

Attachment	Size
84883_subject_newline_2.patch	848 bytes

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