I've had a couple of cases where people reported that they can't “open” a message from me. In each case it was with Microsoft MUAs. On 8 October 2007 I heard from Sue Meaney. Sue was using Microsoft “Internet Explorer” to read mail.

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 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

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 types. 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:

The left-hand column shows the structure of the message and the description, usually the name of the file from which it was attached. 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:

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:

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:

“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) cryptographic signature, but assigned the bogus name ATT00036.dat to it. Ingrid then tried to open it and was greeted with the message:

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?