I've got a script that sends e-mails that looks kinda like this:
$headers = "From: [email protected]\r\n";
$headers .= "Reply-To: [email protected]\r\n";
$headers .= "MIME-Version: 1.0\r\n";
$headers .= "Content-type: text/plain; charset=utf-8\r\n";
$headers .= "Content-Transfer-Encoding: 8bit";
$orgsubject = "A subject with some swedish characters like å, ä and ö";
$newsubject='=?UTF-8?B?'.base64_encode($orgsubject).'?=';
$body = 'A lot of text.
Some more text.
A long URL:
http://example.com/subpage/?id=1234&hash=23jh4lk2j3h4lkjh674598xzxlk2j34h&anotherhash=h2k3j4h23kh42kj34h2lk3';
It's tested thoroughly but some users, I think Outlook users, get a URL looking like this: http://example.com/subpage/?id=3D1234&hash=3D3D23jh4lk2j3h4lkjh674598xzxlk2j34h&anotherhash=3Dh2k3j4h23kh42kj34h2lk3 The equal signs is now followed by '3D' which makes the URL useless in my case. I guess this has something to do with the Content-Transfer-Encoding or perhaps the Content-type, do I need to encode the body message to base64 or something?
Just found this forum post: https://stackoverflow.com/a/7289434/513321 So I removed the Content-Transfer-Encoding and it seems to work fine but on the other hand I could never reproduce the error where the URL contained the '3D' text, so I can't be certain that this will work. Does anyone know if removing the Content-Transfer-Encoding would solve my problem?
Overview. When you use the PHP mail function, you are sending email directly from your web server. This can cause issues if the FROM address isn't set properly or if your email isn't hosted with DreamHost. Sending mail via SMTP is recommended as email is sent from the mail server rather than the web server.
The 7bit is the most fundamental message encoding. Actually, 7bit is not encoded; 7bit encoded files are files that use only 7-bit characters and have lines no longer than 1000 characters.
Content transfer encoding defines encoding methods for transforming binary email message data into the US-ASCII plain text format. This transformation allows the message to travel through older SMTP messaging servers that only support messages in US-ASCII text. Content transfer encoding is defined in RFC 2045.
There’s no mention of this in your question, but the =3D
is an escape sequence of the quoted printable transfer encoding; it’s used to safely transfer 8-bit data using a 7-bit encoding.
There are still mail servers in existence that don’t like lines longer than 76 columns, and intermediate servers MAY mangle your message without updating the message headers, resulting in the observed behaviour.
Since 5.3.0, you can use quoted_printable_encode()
to encode your message and set the Content-Transfer-Encoding header accordingly:
Content-Transfer-Encoding: quoted-printable
Setting an explicit transfer encoding is a good practice you should adopt rather than a naive “somehow it works” approach :)
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With