Blog:The Standard Argument: Incorporating Internet Standards into the Design Process

Blog:The Standard Argument: Incorporating Internet Standards into the Design Process

But it doesn't mean that I'm any less irritated by the original item.

Back in 2006, a kind end-user offered a solution to a reported bug in Microsoft Exchange, addressing how the mail server did not comply with one of the e-mail RFCs (a rather important one, if you ask techies). Somebody from Microsoft replied, saying, "We are considering adding such support in a future release." In 2006. That's two years ago. It's still not fixed, even though they were handed a workaround.

At that point, I decided that I'd talk with Microsoft about it. But if I was going to contact them about RFC-compliance in Exchange, I might as well talk about how the company dealt with all sorts of Internet compliance issues. We might discuss what one e-mail admin told me: "I'd settle for it not rewriting error messages."

Need an example? "501 Invalid hostname in HELO" and "421 Hostname in HELO does not resolve"-from the standard-are both rewritten to "550 no such user", without the original error to give someone a clue. In less technical terms, Exchange replaces the carefully crafted rejection messages (which generally point at URLs identifying the source of the e-mail delivery problem and how to fix it) with bogus information that merely blames someone else. (And you know how I feel about software that assumes that an error is someone else's fault. "Cranky" doesn't begin to cover it.)

I'm no e-mail goddess, but I did manage to learn enough to write an introduction to e-mail technology and an intro to e-mail management. I fully expected that when I talked with the right dude or dudette at Microsoft, we'd talk about, say, how the company decides that their error message reporting is more effective. (Presumably they do.) I could imagine a discussion about the imperfection of the RFCs, because those too are constructed by error-prone humans. (As one e-mail admin explained to me, RFC821 doesn't say what the MTA is supposed to do with 4xx/5xx errors after DATA termination-not in enough detail, anyhow. You can tell that I wouldn't eject someone from a party because she recited RFCs as though they were poetry.)

Or, more generally, I thought, we might talk about SPF records and the features Exchange uses to fight spam. Or maybe we might discuss why some of the default settings in Exchange are, to be kind, not tuned for the poor schnook who is told he's the postmaster even though he has no technical knowledge about e-mail.

Irresistable aside: Like Visual Basic, which was dangerous in the hands of novices simply because anything would be dangerous in the hands of novices, Exchange suffers from being a default choice for people who aren't ready to get educated enough to make an informed one. But because Microsoft knows this (and they surely do), it makes them more responsible for creating useful installation defaults, providing "teach as you go" prompts rather than simple wizards, etc. If you know children will use your product, you should make them child-safe; Microsoft has entirely too many pieces that a baby can swallow. And everyone on the Internet suffers from those errors.

I was looking forward to it, honest.

Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.

Join the newsletter!


Sign up to gain exclusive access to email subscriptions, event invitations, competitions, giveaways, and much more.

Membership is free, and your security and privacy remain protected. View our privacy policy before signing up.

Error: Please check your email address.

More about IETFMicrosoft

Show Comments