I have a problem with special characters in the preheader in iPhone 5. When I send the email shown below (code and headers taken from the hotmail webclient) it shows the special characters (æøå) correct in both subject and the body itself, however, when it's displayed in the preheader it shows ? so some sort of incorrect interpretation of the encoding.
The problem only occurs when opening the email in iPhone (tested with iphone 5) using the native mail client and only when it's linked to a hotmail account. If it's sent to any other acount e.g gmail and opened in the same client it's rendered correctly. The problem has been reproduced on three different iPhones (two of which are running 7.1.2 I do not know what the last one is running).
In the example shown here the characters are html entities, in other tests I've tried with the actual characters with the same result. I've also tried without the meta headers, still same result.
The example is as basic as I can make it, I've tested with more realistic emails and have exactly the same issue.
Has anyone else seen a similar issue, or does anyone know what could cause this problem ?
Subject: =?utf-8?B?w6bDuMOl?=
Content-Type: multipart/mixed;
boundary="----=_Part_434_1665025495.1410355480247"
------=_Part_434_1665025495.1410355480247
Content-Type: multipart/alternative;
boundary="----=_Part_435_224090408.1410355480247"
------=_Part_435_224090408.1410355480247
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
=E6=F8=E5 ABC Webcopy text =09
[image]
Header =09
text =09
[image]
Header =09
text =09
[image]
Text =09
Unsubscribe text =09
------=_Part_435_224090408.1410355480247
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN""http://www.w3.org/TR/html4/loose.dtd" encoding="UTF-8">
<html encoding="UTF-8">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="viewport" content="width=device-width">
<meta name="format-detection" content="telephone=no">
<meta http-equiv="X-UA-Compatible" content="IE=edge" />
<body>
<div>
æøå ABC Webcopy text
</div>
</html>
------=_Part_435_224090408.1410355480247--
------=_Part_434_1665025495.1410355480247--
Finally figured it out.
The preheader is taken from the text/plain version and not the html version, and the text/plain version was encoded as iso-8859-1 and not as the encoding header stated utf-8. After changing the content-encoding header everything worked perfectly.
Related
In my Go application, I'm building and sending multi-part emails with HTML body and PDF attachments. Gmail displays my emails correctly, however the Apple iOS email app doesn't. It only shows the attachment and no text (html) at all.
My emails look like this (I've removed the content for the example):
MIME-Version: 1.0
From: Example <info#example.com>
To: example#gmail.com
Reply-to: info#example.com
Subject: Bla-bla
Content-Type: multipart/alternative;
boundary="3fca6de57f7044cd34adb5454428fd5e5d56e939f26028c745d7b130ca4fa343"
Message-ID: <010201713b392a40-fbba1c61-23e5-44f5-a26a-f83a1598c885-000000#eu-west-1.amazonses.com>
Date: Thu, 2 Apr 2020 14:08:54 +0000
X-SES-Outgoing: 2020.04.02-54.240.7.18
Feedback-ID: 1.eu-west-1.Kpg92BT/SvZS11gkp8+PRgxZ4fKdPt7sUnI7TvXld8g=:AmazonSES
--3fca6de57f7044cd34adb5454428fd5e5d56e939f26028c745d7b130ca4fa343
Content-Type: text/html; charset="UTF-8"
<!DOCTYPE html>
<html lang="en">
<head>
...
</head>
<body>
...
</body>
</html>
--3fca6de57f7044cd34adb5454428fd5e5d56e939f26028c745d7b130ca4fa343
Content-Type: application/pdf; charset="UTF-8"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;filename="afile.pdf"
--3fca6de57f7044cd34adb5454428fd5e5d56e939f26028c745d7b130ca4fa343--
So, I get the email, it has the attachment, but not the text. This only occurs with iOS mail app. By the way, I've googled this issue and found a few topics where iPhone users complained about the same problem with their built-in mail...
Changing the content type of the email itself from multipart/alternative to multipart/mixed helped. Now my emails are displayed correctly both in Gmail and iOS Apple mail.
I've also tried to switch between plain/base64 HTML and inline/no content disposition for HTML part, but that had no effect.
Hope this helps somebody.
I have a multipart/alternative email that works perfectly on Gmail, Yahoo, and any others I've tried... besides Hotmail (and anything Microsoft I presume.)
The email just appears as raw text on Hotmail.
No matter the amount of times I slam my head against the wall and shout swearwords towards Microsoft which has become a daily activity, I cannot figure out why it doesn't work. Can you?
Here is the email if you want to try it yourself:
Headers:
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_18243133_1346573420.1408991447668"
Body:
------=_Part_18243133_1346573420.1408991447668
Content-Type: text/plain; charset=UTF-8
Hello world.
------=_Part_18243133_1346573420.1408991447668
Content-Type: text/html; charset=UTF-8
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<p style="margin-top:50px;font-size:9px;">Hello world</p>
</body></html>
------=_Part_18243133_1346573420.1408991447668--
Here is the full code if you want to test it on your server, either use phpmail or wp_mail() that I'm using.
Update: Here is a source of received message to hotmail.
Probably it is copy-paste to pastbin bug, but your eml contains a space in delimiter line. See here:
--====f230673f9d7c359a81ffebccb88e5d61==
Content-Type: multipart=...<CR><LN>
<SPACE><CR><LN>
^^^^^^^
--====1fdbf23c3658d752511a8dbe74788e30==
If it is not a copy-paste bug than hotmail just can not recognize end of mime entity header.
What you have looks look to be compliant with RFC2046, so it should work with all MUA's (including Hotmail). But having said that, the way this message is structured is somewhat unusual, and it could be that Hotmail just isn't capable of handing such a message properly, even though it is within spec as far as RFC is concerned.
The more common way of structuring a message containing both a plain text body and an HTML body is to specify multipart/mixed in the headers, then create a multipart/alternative section which encompasses both the plain text body part and the HTML body part, using 'subboundaries' (for lack of a better term) to separate the two body parts. See below:
Message Headers
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="====f230673f9d7c359a81ffebccb88e5d61=="
Message Body
--====f230673f9d7c359a81ffebccb88e5d61==
Content-Type: multipart/alternative;
boundary="====1fdbf23c3658d752511a8dbe74788e30=="
--====1fdbf23c3658d752511a8dbe74788e30==
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Hello world.
--====1fdbf23c3658d752511a8dbe74788e30==
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
<p style="margin-top:50px;font-size:9px;">Hello world</p>
</body></html>
--====1fdbf23c3658d752511a8dbe74788e30==--
--====f230673f9d7c359a81ffebccb88e5d61==--
I am working on an integration with OneNote using the REST API.
I'm trying to create a note but I'm always receiving 400 response code, with the following message: "The multi-part payload was malformed."
URL:
https://www.onenote.com/api/v1.0/pages
Headers:
Content-Type: multipart/form-data; boundary=NewPart
Authorization: Bearer myToken
--NewPart
Content-Type: text/html
Content-Disposition: form-data; name="Presentation"
<!DOCTYPE html>
<html>
<head>
<title>One Note test</title>
<meta name="created" content="2014-04-13T10:36:28+01:00"/>
</head>
<body>
<p>Hello OneNote World</p>
</body>
</html>
--NewPart--
If I try the same request in the apigee tool (https://apigee.com/onenote/embed/console/onenote), it's working perfectly.
I have initially tried to not use multi-part, but all the notes sent without multi-part were missing the note body on the OneNote site. Here is my post on this other issue:
OneNote body is not sent when using non-multipart REST
Make sure the presentation part lines end in CRLF. We've noticed that when using some tools like Fiddler, when you try to reissue and edit a previous request, it removes the CRLF endings from the lines.
I have a problem with the mimemail module on drupal 6.
I'm developing a site on a virtual Unix server and the SMTP server is Micorsoft Exchange (on another server of course) and I'm using mimemail and SMTP modules to send emails.
When I configure the SMTP module by itself, everything is correct and I receive the test message in the correct format.
If I enable mimemail, set the "Use mime mail for all messages" and then I configure the SMTP, the message arrives but it is not correctly encoded.
I hope that someone can give me an help.
I spent a lot of time searching the web for a solution but I was not able to find an answer.
Here is the test message I receive:
This is a multi-part message in MIME format.
--ca2a0ce37a649a90e1efc6d650f2387c
Content-Type: multipart/mixed; boundary="44b02f56426ca5bf19322ab80ca53d99"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
--44b02f56426ca5bf19322ab80ca53d99
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
If you receive this message it means your site is capable of sending e-mail.
--44b02f56426ca5bf19322ab80ca53d99
Content-Type: text/html; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<style type="text/css">
<!--
#charset "UTF-8";
body{background:#FFF;}
*{font-family:Arial,Helvetica,sans-serif;font-size:12px;color:#006;}
-->
</style>
</head>
<body id="mimemail-body" class="mail-smtp-smtp-test">
<div id="center">
<div id="main">
<p>If you receive this message it means your site is capable of sending e-mail.</p>
</div>
</div>
</body>
</html>
--44b02f56426ca5bf19322ab80ca53d99--
--ca2a0ce37a649a90e1efc6d650f2387c--
I'm trying to get a simple Lift example running and I'm having a strange issue. I am using the Sonatype sample list project here. I modified the HTML slightly, but it wasn't working originally either. The issue I'm having is that when I run the local jetty server and try to access http://localhost:8080 it displays as XML in Firefox 3.6.10 rather than HTML. Note, it displays fine in IE8 but the Content-Type in IE8 is "text/html". I assume Firefox doesn't like the Content-Type "application/xhtml+xml" for some reason. The message in Firefox says:
This XML file does not appear to have
any style information associated with
it. The document tree is shown below.
Below are the response headers from Firebug:
Expires Thu, 16 Sep 2010 03:55:04 UTC
Content-Length 558
Cache-Control no-cache; private; no-store
Content-Type application/xhtml+xml; charset=utf-8
Pragma no-cache
Date Thu, 16 Sep 2010 03:55:04 UTC
X-Lift-Version 2.0-scala280-SNAPSHOT
Server Jetty(6.1.22)
..and the actual response:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html>
<head>
<title>Lift Test</title>
</head>
<body>
<h2>Welcome to your project!</h2>
<p>
<span>Welcome to toto01 at Wed Sep 15 20:55:04 PDT 2010</span>
</p>
<script type="text/javascript" src="/ajax_request/liftAjax.js"></script>
<script type="text/javascript">
// <![CDATA[
var lift_page = "F586508075515C1K";
// ]]>
</script>
</body>
</html>
Any ideas as to what is going wrong? How would I change the Content-Type in Lift for Firefox if that is the issue?
Alright, it looks like the problem is related to the element not having an xmlns attribute. After changing the XHTML to below it worked fine with the content type as "application/xhtml+xml":
<html xmlns="http://www.w3.org/1999/xhtml">
The problem should be in the use of both application/xhtml+xml content type and XHTML transitional dtd.
https://developer.mozilla.org/en/Mozilla_Web_Developer_FAQ