|
|
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).
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.
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:
Image title: muttoriginal Dimensions: 739 x 195, 120 kB Dimensions of original: 739 x 195, 120 kB Display this image:
thumbnail hidden alone on pageDisplay all images on this page as:
thumbnails this sizeShow for Thursday, 5 January 2006:
thumbnails small images diary entryThe 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:
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:
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 pageDisplay all images on this page as:
thumbnails this sizeShow 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:
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 pageDisplay all images on this page as:
thumbnails this sizeShow 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:
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 pageDisplay all images on this page as:
thumbnails this sizeShow for Thursday, 5 January 2006:
thumbnails small images diary entryIt 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 |