Broken mail handling
Greg's rants
Greg's home page
Greg's diary
Greg's photos
Greg's links
Google

Have you had a message from me which appears empty, or which contains attachments which your MUA (mail user agent, often referred to as “Mailer” or “Mail reader”) claims could be dangerous? Or maybe you just can't “open” a message from me. If so, you're probably using a Microsoft MUA, and you've tripped over a Microsoft bug (or maybe it's a “feature” designed to confuse you).

Summary

In all probability your MUA is getting confused about the digital signature with which I sign my mail messages. This signature is a special attachment that proves that the message comes from me (nobody else can generate it). Read my page about digitally signed mail for more details. The problem is that Microsoft MUAs in particular often get completely confused by it.

The basic issue here is that Microsoft handles mail messages incorrectly. It insists on “file names” for components (“attachments”) of mail messages, because that's the only way it identifies their content type. That's in violation of the Internet standards.

My signatures and other attachments do not have file names, because they're not files. But when a Microsoft MUA sees an attachment without a file name, it gives it an invented file name ending in .dat. It then complains about this name, because it claims that “opening” it could be dangerous.

This warning is wrong. In the usual case of digital signatures, Microsoft can't interpret this signature (though the Microsoft Security Response Center uses them!), so if you're using Microsoft MUAs, you might as well ignore any attachment with a “file name” like ATT00036.dat.

There is a possibility, of course, that this isn't what you're seeing. One thing's for sure: I don't send out any dangerous mail. But others do, and some put my name on the messages. If you see something dubious that doesn't match this description, please let me know.

The technical explanation

For example, on 8 October 2007 I heard from Sue Meaney, who was using Microsoft “Internet Explorer” to read mail, and she couldn't “open” an attachment.

The issue here is how Microsoft handles email. Nearly all Email today uses MIME, the Multipurpose Mail Extensions. They allow messages to consist of multiple parts with different purposes. The purpose is described by a header with the name Content-type:. The message I sent to Sue was digitally signed and had three such headers:

Content-Type: multipart/signed; micalg=pgp-sha1;
    protocol="application/pgp-signature"; boundary="hHiQ9nAwW5IGN2dL"
Content-Type: text/plain; charset=us-ascii
Content-Type: application/pgp-signature

In the original message, these headers occur at different places in the message. The first header (continued onto a second line) describes the message as a whole. It's multipart/signed, which contains two other parts: the first is the message itself (which, in fact, simply said “Thanks, Sue”), and the second is a digital signature confirming that it could only have come from me.

So what was Sue's problem? Microsoft, of course. Microsoft doesn't believe in Content-Type:; indeed, the message that Sue had sent me contained a PDF attachment, which should have a Content-Type: of application/pdf. Instead, what my MUA saw was:

Content-Type: application/octet-stream;
    name="10-08-2007(2).pdf"

application/octet-stream gives no information at all about the nature of the attachment, simply that Microsoft hasn't tried to mangle it. How can I know what it is? I have to guess, based on the name specified. It ends in .pdf, which is the insecure way Microsoft uses to identify file content. MIME allows this, but it's operating-system specific, so it's not a good idea. There's still no excuse for not supplying a valid Content-type:.

But things get worse. My signature doesn't have a file name, because it's not a file. Microsoft doesn't like that. I've seen this problem before when submitting expense reports. Here's a writeup with screen shots that show the problem:

Message from Ingrid Goethe today: she had difficulty with the expense report I sent her yesterday. I had sent a lot of attachments, including plain text, a couple of PDFs, and some PNGs of scanned-in receipts. As usual, I digitally signed my message. Here's how mutt saw the result:

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060105/big/muttoriginal.jpeg
Image title: muttoriginal
Dimensions: 739 x 195, 120 kB
Dimensions of original: 739 x 195, 120 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Thursday, 5 January 2006:
thumbnails    small images    diary entry

The left-hand column shows the structure of the message and the description. If it's a file which has been attached, it's the name of the file, for example 2005-12.pdf or 2005-11-MySQL.report. In the case of attachments not associated with a file, there is no description. The right-hand column shows the MIME type, the encoding and the size.

Ingrid's using Microsoft, however, and it had a completely different view:


https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060105/big/Microsoft-rendition-1.jpeg
Image title: Microsoft rendition 1          Dimensions:          856 x 128, 60 kB
Make a single page with this image Hide this image
Make this image a thumbnail Make thumbnails of all images on this page
Make this image small again Display small version of all images on this page
All images taken on Thursday, 5 January 2006, thumbnails          All images taken on Thursday, 5 January 2006, small
Diary entry for Thursday, 5 January 2006

 

Note particularly that the digital signature, which didn't have a name, has been called ATT00036.dat, and the lack of MIME information, It might appear that the icons associated with the names are derived from the MIME type, but that's not the case: they're derived from the “extension” of the description.

The first problem was looking at 2005-11-MySQL.report, a text/plain attachment. Microsoft completely ignored the MIME type and said:

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060105/big/attachment-1.jpeg
Image title: attachment 1
Dimensions: 362 x 195, 46 kB
Dimensions of original: 362 x 195, 46 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Thursday, 5 January 2006:
thumbnails    small images    diary entry

This abuse of the word “open” gets on my nerves, but why didn't it just display it? On pressing the Open button, another message was shown:

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060105/big/attachment-2.jpeg
Image title: attachment 2
Dimensions: 415 x 262, 60 kB
Dimensions of original: 415 x 262, 60 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Thursday, 5 January 2006:
thumbnails    small images    diary entry

To open this file, Windows needs to know what program created it.”. What nonsense! It's none of “Windows”' business what program created it (it was, in fact, an awk script). The important thing is that you need to know what kind of data it is. That's what the MIME type is about: it's plain text. You can select Select the program from a list (never mind that this assumes that the program that created it can also “open” it, not the case for awk) and select Notepad, and it will be displayed correctly. But how is any recipient to know that when “Windows” hides as basic information as the MIME type?

It's interesting to note that this nonsense is also one of Microsoft's most avoidable security issues (or at least, it was last time I looked): since Microsoft ignores the MIME type, you can send an executable attachment with a name like foo.txt, and it'll merrily execute it for you.

That wasn't all, though. As shown above, Microsoft also not only hid the MIME type of the (anonymous) digital signature, but assigned the bogus name ATT00036.dat to it. Ingrid then tried to open it and was greeted with the message:

 
https://lemis.nyc3.digitaloceanspaces.com/grog/Photos/20060105/big/attachment-3.jpeg
Image title: attachment 3
Dimensions: 413 x 180, 42 kB
Dimensions of original: 413 x 180, 42 kB
Display this image:
thumbnail    hidden   alone on page
Display all images on this page as:
thumbnails    this size
Show for Thursday, 5 January 2006:
thumbnails    small images    diary entry

It seems that the ending .dat is special for Microsoft. So why use such a name for an attachment that doesn't have a name?

This problem caused both Ingrid and myself several hours of pain. If Microsoft “Outlook” would just adhere to the standards, there wouldn't have been any problem. It's this kind of nonsense, and not Microsoft's predatory commercial policy, that most annoys me about Microsoft.

Summary

To summarize, Microsoft has shot itself in the foot here:

  • First, it ignores MIME types and insists on an operating-system specific name. What if the operating system uses different names? For example, if I send a JPEG image as photo.jpeg, where Microsoft expects it to be called photo.jpg? Maybe it knows this exception, but I'd guess that it won't know them all.

  • Microsoft attempts to “recover” from the fact that the attachment doesn't have name (and ignores the fact that it doesn't need one) by assigning a name, in this case ATT00036.dat.

  • This doesn't help at all, of course, because the name is unrelated to the content.

  • Worse still, though, it has chosen a name that it considers special, and which it refuses to display (or “open”, as it calls it).

Is this user-friendly?


Greg's home page Greg's diary Greg's photos Copyright

Valid XHTML 1.0!

$Id: broken-MUA.php,v 1.15 2022/01/01 01:43:23 grog Exp $