Simple question...
I have seen people tell me to use "\r\n" in various places and others tell me to use "\n" in the same place. I'm sure one is right and one is wrong. Example - when designing mail() headers:
Tutorial #1:
//define the headers we want passed. Note that they are separated with \r\n
$headers = "From: webmaster#example.com\r\nReply-To: webmaster#example.com";
//add boundary string and mime type specification
$headers .= "\r\nContent-Type: multipart/mixed; boundary=\"PHP-mixed-".$random_hash."\"";
Tutorial #2 (notice the header argument):
mail($to, $subject, $body,
"From: " . $from . "\n" .
"bcc: " . $bcc . "\n" .
"MIME-Version: 1.0\n" .
"Content-Type: multipart/alternative;\n" .
" boundary=" . $mime_boundary_header)
I am confused, but clearly it makes somewhat of a difference, because with one, my headers worked, and with the other they only sometimes work.
\r\n are end of line characters for Windows systems.
\n is the end of line character for UNIX systems.
These characters are invisible. From my own experience \n is usually okay for Windows as well.
Some prefer to use PHP_EOL constant instead of these characters for portability between platforms.
echo 'hi' . PHP_EOL;
echo "hi\n";
$headers = "From: webmaster#example.com" . PHP_EOL
. "Reply-To: webmaster#example.com";
As per RFC 821 (the SMTP protocol), line endings should always be \r\n (<CR><LF>) in mail headers and content, but in practice it shouldn't matter as most mail servers handle all three type of line endings correctly (supposedly, some old UNIX-based ones actually choke on \r\n but not \n).
In addition to Yada's answer, here is an explaining blog entry: https://blog.codinghorror.com/the-great-newline-schism/
[Update 2017-05-24: Fixed the link]
Related
An error with the php error_log function when selecting message_type 1 and sending an email. Any value I place in the extra_headers parameter, stops any email being received and the error created.
$headers = "MIME-Version: 1.0\r\n";
$headers .= "Content-Type: text/html; charset=ISO-8859-1\r\n";
$headers .= 'From: error-404#'.substr($_SERVER['SERVER_NAME'],4)."\r\n";
$log = var_export(debug_backtrace(), true);
error_log("<HTML><body><h1>404 ERROR: $today</h1><br /><p>$log</p></body></HTML>", 1, "webmaster#domain.com", $headers);
mod_fcgid: stderr: PHP Warning: error_log(): Multiple or malformed newlines found in additional_header in .....
Current PHP version: 5.6.24
Thanks.
The documentation of function error_log() for argument $extra_headers says:
This message type uses the same internal function as mail() does.
The documentation of function mail() says for $additional_headers:
Multiple extra headers should be separated with a CRLF (\r\n)
This is (I hope) the reason you use CRLF (\r\n) to separate the lines in the mail header.
However, the same documentation page also says in a note, several paragraphs below:
If messages are not received, try using a LF (\n) only. Some Unix mail transfer agents (most notably » qmail) replace LF by CRLF automatically (which leads to doubling CR if CRLF is used). This should be a last resort, as it does not comply with » RFC 2822.
I cannot tell about qmail but I encountered the same behaviour when the email server was sendmail. The problem vanished when I used LF (\n) as the end-of-line marker in the headers.
This has worked for me. Not too sure how correct this solution is.
//create a boundary string. It must be unique so we use the MD5 algorithm to generate a random hash
$random_hash = md5(date('r', time()));
//define the headers we want passed. Note that they are separated with \r\n
$headers = "From: $from_name <$from_mail> \r\nReply-To: $from_mail";
//add boundary string and mime type specification
$headers .= "\r\nContent-Type: text/html; charset=\"iso-8859-1\"; boundary=\"PHP-alt-".$random_hash."\"";
error_log($sMsg, 1, $emailto, $headers);
I hope it helps somebody else.
Thank you for all your replies.
Do not end extra_header with newline.
Below code is OK:
error_log("sometext", 1, "ohmyson#gmail.com",
"Subject: Foo\nFrom: Rizzlas#my.domain");
I am attempting to use the built-in "mail" function in PHP, which has worked fine for my needs in a hosted LAMP environment with SiteGround. In this case I am running my own server on Windows, and my messages arrive with a spurious character (a capital 'B') prepended to the body text. I have tried replacing $mailBody in the call with a simple 'abc' string, and the spurious capital 'B' is still prepended. I am guessing that the problem is caused by a character-encoding mismatch. I have tried altering the "Content-type" in the header from text/plain to text/html, and the charset from windows-1251 to utf-8, neither of which make any difference.
$headers = "MIME-Version: 1.0\r\n";
$headers .= "Content-type: text/plain; charset=windows-1251\r\n";
$headers .= "From: $confirmation_sender\r\n";
$bMailSuccess = mail ($strEmail, $business_name . ' Booking Confirmation', $mailBody, $headers);
php.ini
SMTP = internalmail
As you can see, mail is directed to a server called 'internalmail', and the logs on this server suggest that the spurious character is already part of the body text that it receives. Can anyone suggest a fix (preferably other than "install some other mail client")?
Over the weekend our MTA (POSTFIX) suddenly started prepending line breaks to the boundaries of our messages.
We have several PHP templates that define multipart/alternative messages and define the headers.
Here is the PHP mailer format, which was working friday, then just suddenly stopped on monday.
$headers = "From: name <our#example.com>\r\n" .
"Reply-To: name <our#example.com>\r\n" .
"MIME-Version: 1.0\r\n" .
"Content-Type: multipart/alternative; boundary=\"09127kjhd821\"";
$txt = "\r\n\r\n--09127kjhd821\r\n" .
"Content-Type: text/plain; charset=UTF-8\r\n" .
"Content-Transfer-Encoding: quoted-printable\r\n\r\n" .
"Text Message";
$html = "\r\n\r\n--09127kjhd821\r\n".
"Content-Type: text/html; charset=UTF-8\r\n" .
"Content-Transfer-Encoding: base64\r\n\r\n" .
chunk_split( base64_encode( "HTML Message") );
$body = $txt . $html . "\r\n\r\n--09127kjhd821--";
mail(
"someone#example.com",
"=?UTF-8?B?" . base64_encode( "Subject" ) . "?=",
$body,
$headers
);
Comparing the original mails to the broken ones i see the following
Broken:
Date: Fri, 3 Aug 2012 16:52:39 -0400 (EDT)
--09127kjhd821
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Original (Working)
Date: Tue, 31 Jul 2012 12:36:45 -0400 (EDT)
--09127kjhd821
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
As you can see the line breaks are off pretty much doubling for each \r and \n, nothing was changed to my knowledge that would cause this.
Any suggestions or help is greatly appreciated.
The only thing I can come up with is the POSTFIX and PHP issues with converting LF to CRLF so when CRLF is defined in the message body for boundaries and headers it is being converted to CRCRLF.
Saving the message source however only displays as CRLF in the hex editor though, which may be a conversion in the editor I use or email client download process.
I still don't understand why it just suddenly changed as it was working fine previously.
The only difference I can think of is maybe due to the scripts line-endings that may have changed from CRLF to LF causing a conversion to take place and thus breaking emails that contain CRLF in the body.
I ultimately fixed the issue by changing the sendmail_path in php.ini to
sendmail_path="/usr/bin/dos2unix|/usr/sbin/sendmail -t -i"
I've seen a lot of examples using the php mail function. Some of them use \r\n as line break for the header, some use \n.
$headers = "From: Just Me\n";
$headers .= "Reply-To: Just me <$email>\n";
vs
$headers = "From: Just Me\r\n";
$headers .= "Reply-To: Just me <$email>\r\n";
which one is correct?
Sometimes I've had cases where \r\n is used and part of the header is interpreted by some email clients as mail text (losing these header information) - is this because \r\n is wrong?
The CRLF \r\n, should be used according to the php documentation. Also, to conform to the RFC 2822 spec lines must be delimited by the carriage return character, CR \r immediately followed by the line feed, LF \n.
Since \r\n is native to Windows platforms and \n to Unix, you can use the PHP_EOLDocs constant on Windows, which is the appropriate new line character for the platform the script is currently running on.
Just in case a search engine picks this up and saves someone else the frustration I went through: here's an additional curiousity.
On php 5.2x on Linux, I had \r\n on my email headers in php mail(), after an upgrade to php 5.3.3, the formatting and sending mysteriously failed. Removing the \r fixed the script (after examining many many other possibilities).
As stated above, \r\n is what you should use according to the RFC, but this breaks your headers on several mail systems (f.i. Outlook 2003). Even though \n is not the 'proper' line break to use, in my experience it works correctly on all mail systems I've encountered so far. Because of this, I always use just \n.
The RFC formally mandates CRLF (\r\n) but using Unix breaks (\n) for headers will save you a lot of hassle. Some mail servers, such as qmail, will reject your message if it uses \r\n.
Source: experience, confirmed by this note: http://www.php.net/function.mail#40204
My experience:
HTML emails were working in web clients, but breaking in MS based desktop clients (entourage, outlook). Was using \r\n. Removed the \r on the MIME-Version only and now works across the board.
I've had the problem of gmail misunderstanding \r\n headers, but simply leaving the header line breaks at \n was not enough in my case, because in that case some versions of Outlook showed emails as empty.
The solution in https://stackoverflow.com/a/7960957 (I chose to install postfix 2.9 on lucid from a ppa) coupled with using \n seems to work everywhere now.
I changed my script to use PHP_EOL instead which seems to work -- like this:
//Set Content-type header
$headers = "MIME-Version: 1.0" . PHP_EOL;
$headers .= "Content-type: text/html; charset=iso-8859-1" . PHP_EOL;
//Additional headers
$headers .= "From: $from" . PHP_EOL;
$headers .= "Cc: $cc" . PHP_EOL;
$headers .= "Content-type: text/html" . PHP_EOL;
$headers .= "Bcc: $bcc" . PHP_EOL;
NB. Be sure to us " instead of ' as the latter doesn't seem to work!
> $mail = new PHPMailer;
$mail->isSMTP();
**$mail->isHTML(true);**
Insert this code after working
> all html tag <br> <p> in $mail->Body='Hello<br> how are you ?<b>';
hellHi Folks,
I have a contact form on my webpage, and it workd fine so far.
Only problem is, that in my mailprogram, the name in the from field doesn't show correctly, although the sourcecode of the email seems correct:
From: Metaldemos <hello#metaldemos.com>
Reply-To: Metaldemos <hello#metaldemos.com>
Anyway, in the mailprogram, the name is 'hello'.
In php I use this headers:
$headers="Mime-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: quoted-printable\nFrom: Metaldemos <hello#metaldemos.com>\nReply-To: Metaldemos <hello#metaldemos.com>\nReturn-Path: Metaldemos <hello#metaldemos.com>\n";
and the code for sending the mail:
mail($email, $subject, $mailbody, $headers,"-t -i -f Metaldemos <hello#metaldemos.com>");
Any idea on how I can fix this?
Greetz & thanks
Maenny
The above answer is correct. You need the \r\n at at the end of the "From" and "Reply-To" lines. AS WELL as at the end of ALL the other header lines.
According to the SMTP RFC (section "2.3.8. Lines")
Lines consist of zero or more data characters terminated by the
sequence ASCII character "CR" (hex value 0D) followed immediately by
ASCII character "LF" (hex value 0A). This termination sequence is
denoted as in this document. Conforming implementations MUST
NOT recognize or generate any other character or character sequence
as a line terminator. Limits MAY be imposed on line lengths by
servers (see Section 4).
In addition, the appearance of "bare" "CR" or "LF" characters in text
(i.e., either without the other) has a long history of causing
problems in mail implementations and applications that use the mail
system as a tool. SMTP client implementations MUST NOT transmit
these characters except when they are intended as line terminators
and then MUST, as indicated above, transmit them only as a
sequence.
So your header line of:
$headers="Mime-Version: 1.0\nContent-Type: text/plain; charset=UTF-8\nContent-Transfer-Encoding: quoted-printable\nFrom: Metaldemos <hello#metaldemos.com>\nReply-To: Metaldemos <hello#metaldemos.com>\nReturn-Path: Metaldemos <hello#metaldemos.com>\n";
is invalid, HTTP or SMTP headers MUST always end with \r\n not just a \n or \r
The correct line would be
$headers="Mime-Version: 1.0\r\n";
$headers.="Content-Type: text/plain; charset=UTF-8\n";
$headers.="Content-Transfer-Encoding: quoted-printable\n";
$headers.="From: Metaldemos <hello#metaldemos.com>\n";
$headers.="Reply-To: Metaldemos <hello#metaldemos.com>\n";
$headers.="Return-Path: Metaldemos <hello#metaldemos.com>\n";
You CAN put it all in one long line that's fine, I just split it up to make it clearer.
The reason it didn't work before is because you only changed FROM and REPLY-TO you have to change all of them.
Try adding both a carriage return and new line character. I know when I'm writing PHP scripts to send mail, I do something similar to the following:
...
$headers.= "From: John Doe <john.doe#example.com>\r\n";
$headers.= "Reply-To: Jane Doe <jane.doe#example.com>\r\n";
...
if (mail($to, $subject, $message, $headers)) {
// email sent
}
else {
// email failed
}