Return Address: Arrogance, MS

Chris DiBona, a man of many titles (Linux Community Evangelist, VA Linux Systems; President, Silicon Valley Linux Users Group; Grant Chair, Linux International) passed to us this reminder that for all the (occasionally legitimate) claims of standards compliance out of Redmond, subtly breaking standards in the name of "improvement" can be far worse than more blatant attempts. Hint: supplanting ASCII is a bad idea. (More below.)

Chris writes: " So here's an interesting feature from our friends at MicroSoft. They've decided that Outlook 2000 users by default really don't want to communicate with the rest of the world, preferring to communicate only with other OL2000 users.

Now, while I don't have any problem with people extending the content of an e-mail with attachments, i.e. sending html-ized version and v.cards, it seems downright stupid to make the default behavior of ol2000 to send it's e-mail only in MS's proprietary TNEF format.

Now, It's clear that they've had some support calls on this, as proven by this KB Entry. So that means that they caught some flak for it. But they haven't changed it.

Fun Quotes from the KB entry:

• In addition to the receiving client, it is not uncommon for a mail server to strip out TNEF information from mail messages as it delivers them. If a server option to remove TNEF is turned on, clients will always receive a plain text version of the message. Microsoft Exchange Server is an example of a mail server application that has the option to remove TNEF from messages.

This means in essence that unless you are using a 'TNEF Aware' server -- like, say, hmm, MS Exchange -- you may not be able to read your mail. I may be reading a bit much into this paragraph, but it seems to me that this paragraph says 'if your friends can't get your email, it's their servers fault, not yours.'

And to take this the further, go join the EFF if you haven't already, step, suppose somone were to circumvent the protections on the TNEF format and write a program that could understand it, would you be liable under the DMCA section on anti-circumvention? Admittedly, I'd be surprised if MS took this route, but it's worth considering every single time you think about decoding proprietary formats. Does this mean strings is now a circumvention tool?

Anyhow, if there are any microsofties out there, do the right thing and cut down your support costs by making ascii the ol2000 default transmission behavior for text. And for anyone using Outlook 2000, you should switch to a program that your friends can actually recieve email from. Or at least shut off that option."

Comments

OL2000

[mindstrm]

Strange. I have several dozen users using outlook 2000, and other users using Eudora, Netscape, OL Express, and heck I use unix mail (pine etc...). ANd to boot, many versions of each.

OL2000 seems to have no problem sending mail to others. And we are NOT using an exchange server that translates mail for people.

Now there IS a problem, that may or may not be related, whereby some attachments sent in OL can only be read by other OL users.. but that usually has to do with RTF messages (using embedded objects instead of attachments or some such thing).

For those that don't know, Outlook was really designed to be run with MS Exchange server. The server can be configured to handle mail translation for it's clients, so internally, an office can have the benefits of a more advanced(?) mail system (in an office workgroup sense), and externally, the world can get ASCII.

NOt sure where the big problem is though...

You know, I still hate MS, but after a few years in a larger network... I've come to realize that all MS tools are not bad, they are just generally used for the wrong things. This is partly (mostly?) Microsoft's fault. Saying 'using OL with exchange server provides an excellent messaging platform for your company' is very different than saying 'use outlook for mail, it rocks'. They want people to use their crap for everythingl.
But some of it, if used in the way intended, can be useful to a large degree.

Apply This Rule.

[istartedi]

Whenever I run accross a new piece of software, I always like to apply this rule. It requires you to use your imagination a little.

Imagine that you are sitting in a room full of vacuum tubes at the moment the first modern digital computer was assembled. After the initial glee, the engineers all sit around and brainstorm for ideas about where it will lead. The continuously shout out: "This is great! Someday we'll be able to (blank)".

Now, take the new piece of software, hardware, or application, and fit it in the blank.

So, we have "This is great! Someday we will be able to (transmit text only to people who have our particular program)" vs. "This is great! Someday we will be able to (transmit text in a universal format that all systems can understand)"

Now, to be fair, the MS format might have some advantage over ASCII. What, I don't know. After all, we already have the UTF standard for the handling of foreign character sets, so it can't offer that. So, I challenge anybody to fill in the blank: "This is great! Someday we will be able to (blank)" and put this MS format in a good light.

I will be amazed if anybody can do that.

BTW, you may think my little thought experiment is klutzy, but it works much more quickly in my mind than it does when I am trying to explain it on /..

Chris Dibona - making a mountain out of a molehill

[Frac]

I quote from the KB article:

When a message containing TNEF information is received by a mail client that does not understand TNEF, there are three common results:

The plain text version of the message is received and it contains an attachment named Winmail.dat. The Winmail.dat attachment does not contain any useful information when opened since it is in the special TNEF format.

The plain text version of the message is received and it contains an attachment with a generic name such as ATT00008.dat or ATT00005.eml. In this case the client is unable to recognize the TNEF part of the message, and is unable to recognize the Winmail.dat file name, so it creates a file name to hold the TNEF information.

The plain text version of the message is received and the client ignores the Winmail.dat attachment. This is the behavior found in Microsoft Outlook Express. Outlook Express does not understand TNEF, but it does know to ignore TNEF information. The result is a plain text message.

There is NO MENTION anywhere that non-Outlook users will not get an e-mail. At worse, the message will be received as plain text. (Oh no!)

Actually, I HOPE that all those servers will strip out the TNEF information, because I'm sick of trying to parse HTML in my own head.

Actually supplanting ASCII is inevitable...

[crovira]

ASCII is an acronym for American Standard Code for Information Interchange.

There's 225 million American, 5.8 billion other people on this planet, most whom don't speak English and don't write in modified, vowel poor, aplhabets.

Can you say "ASCII is cutting us off from big potential markets?" Sure... I knew you could...

Unicode will spread because it's NEEDED.

This is what TNEF actually is

[gattaca]

I must admit, I didn't know exactly what TNEF was, and I got the impression that a few other people who were posting didn't either.

This is what I found at CSGNetwork's Online Computer, Telephony & Electronics Reference

Pronounced tee-neff, and short for Transport Neutral Encapsulation
Format, a proprietary format used by the Microsoft Exchange and
Outlook E-Mail clients when sending messages formatted as Rich Text
Format (RTF). When Microsoft Exchange thinks that it is sending a
message to another Microsoft E-Mail client, it extracts all the
formatting information and encodes it in a special TNEF block. It then
sends the message in two parts - the text message with the formatting
removed and the formatting instructions in the TNEF block. On the
receiving side, a Microsoft e-mail client processes the TNEF block and
re-formats the message. Unfortunately, most non-Microsoft E-Mail
clients cannot decipher TNEF blocks. Consequently, when you receive a
TNEF-encoded message with a non-Microsoft e-mail client, the TNEF part
appears as a long sequence of hexadecimal digits, either in the
message itself or as an attached file (usually named
WINMAIL.DAT). These WINMAIL.DAT files serve no useful purpose so you
can delete them.

So it's not UNICODE or something like it, it's extra formatting information that, unfortunately, is proprietary.

Bullshit

[donutello]

I've been using Outlook 2000 for a little over a year now. I communicate with a lot of people, including people who use elm as their client. I have hardly ever bothered to change the format of the messages I have sent. I have yet to receive a single complaint about my messages being unreadable. Quite obviously, there isn't a problem.

As for it supplanting ASCII, what part of "Plain Text is not Rich Text" do I need to explain again?

This is getting tiresome. Slashdots editors need to take at least the basic steps required to verify a story before rushing to post it just because it gives them a chance to bring out their Bill-Gates-As-The-Borg icon. I don't know, maybe stopping for a second and THINKING about it - Outlook 2000 has been out for more than a year now - wouldn't you have heard about this before if it was true?

And don't even get me started about the so-called expert who wrote the article in the first place.

He is correct.

[Fervent]

He is correct. Outlook can be made quite easily to send HTML-only mail. The extensions this [clearly uneducated pseudo-]journalist is talking about only deal with special meeting and scheduling tags used within Outlook. Outside Outlook there would really be no reason to have them (for example, what would KMail use with a "meeting at 2:00 PM" tag?)

This is more or less a classic example of not getting enough information then placing blame on a non-blameworthy party. Beating up on Microsoft is in fashion, remember (soon it will be beating up on RedHat, then Yahoo, then AMD, etc.). It's a cycle.

Open source TNEF decoder

[Prolog-X]

is here.