Anyone else seeing failure of FM client to detect an .MHTML attachment from Gmail?
 

Gmail shows the message fine https://i.imgur.com/9C7jnSR.png

But Fastmail pretends there is no attachment https://i.imgur.com/cA5rATu.png . In Chrome and Firefox.

Anyone else see this?

This is a rather serious misrep of the message content by Fastmail.

MHT and MHTML transfer as email attachment is not reliable
 

".mht" and ".mhtml" attachments are treated in different ways by various email systems.

• Some (Gmail to Fastmail) treat them as
  Content-Type: message/rfc822;
  This seems to produce an empty display (either previewed in the Fastmail web interface or downloaded and viewed in Internet Explorer).
• Others (Outlook.com sent to Fastmail or Gmail) treat them as
  Content-Type: application/octet-stream;
  These can be downloaded and viewed correctly using Internet Explorer from either the Fastmail or Gmail web interface.
• Gmail to Outlook.com produces very odd results. These are treated as
  Content-Type: message/rfc822;
  A 225 KB .mht attachment sent from Gmail to Outlook.com and auto-forwarded to Fastmail results in:
  • 914 byte placeholder only in Outlook.com
  • 34 byte placeholder only in Fastmail after forwarding
• Fastmail to Fastmail produces a proper sized attachment which can be previewed properly using the Fastmail web interface (see screen image capture here) but which is displayed improperly when downloaded and viewed in Internet Explorer.
• Fastmail to Gmail are treated as
  Content-Type: message/rfc822;
  These can't be previewed (Gmail limitation) but can be downloaded and displayed properly in Internet Explorer.

So unless you use a zip or similar container I think you can't depend on .mht or .mhtml attachments getting properly through email transfer.

Thanks for that info.

I see no such Content-Type in what Gmail sends for MHTML. I see e.g.:

Content-Type: multipart/related; name="Chris's Home Page.mhtml"
Content-Disposition: attachment; filename="Chris's Home Page.mhtml"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_jm2c5v5b0

The problem I'm reporting here is Fastmail pretends there is no attachment. It shows no attachment thumbnail.

Still I'd be interested to hear if anyone else gets this.

Again, I see different in what Fastmail sends for MHTML:

Content-Disposition: attachment; filename="Chris's Home Page.mhtml"
Content-Id: <1536949649.3564772.d2b39525c9c2d89d8243885531907724a2abcc08.636CFA99@content.messagingengine.com>
Content-Transfer-Encoding: 8bit
Content-Type: application/octet-stream; name="Chris's Home Page.mhtml"

My point is that Outlook.com to Fastmail works fine. It’s the Gmail outbound that seems to create an odd message format which can’t be read by Fastmail or Outlook.com. I sent a message from Gmail with To addresses at Fastmail and Outlook.com (one message with two recipients) and they were both received in a way which I think indicates that they were not properly parsed. Each receiving system interpreted the Gmail MHT attachment differently and neither was correct.

The problem is the Content-Type in the MIME block encapsulation and the MIME formatting. Look for the Content-Type header down at the start of the MIME block, not in the main contiguous header list before the first blank line. Both Fastmail and a Outlook.com can’t parse what Gmail is sending, leading to what both you and I reported. I found this old complaint;
https://support.google.com/mail/foru...Gm4nj4M/?hl=en

I created my MHT and MHTM files using both of these methods and they both work as I described:

1. Internet Explorer viewing the Fastmail main signin page and using Save As...
2. Microsoft Word using text and embedded photo and Save As...

It’s a Microsoft format, I think. How are you creating your MHT file? Are you using the Gmail web interface to send it or a SMTP client?

Bill

Understood. But I'm not seeing that. I'm not seeing anything odd about the Gmail message as sent. In particular I'm not seeing /rfc822.

I did. Here's all the MIME headers: https://i.imgur.com/j7nLP4m.png

Chrome Save.

Gmail web interface.