Coding Horror

I have modest email needs, so I use the default SMTP and POP3 services in Windows Server 2003. Although I have email relay disabled, spammers are still managing to send spam through my SMTP service -- via non-delivery reports!

In other words, spammers are intentionally sending email messages to nonexistent email addresses on my domain. Here's a representative sniffer trace from earlier today:

MAIL FROM:<lolando@glocos.com>
250 2.1.0 OK
RCPT TO:<uucp@codinghorror.com>
250 2.1.5 OK
354 Start mail input
DATA
(spam email body elided)
250 2.6.0  Queued mail for delivery

MAIL FROM:<meskes@getinthepicture.com>
250 2.1.0 OK
RCPT TO:<support@codinghorror.com>
250 2.1.5 OK
DATA
(spam email body elided)
250 2.6.0  Queued mail for delivery

This repeats dozens of times, with different from and to email address. The person in the "from" address will get a non-delivery report from my server that includes the original spam message as an attachment.

This is also known as a "Reverse NDR attack", because the non-delivery report goes to the recipient (eg, the victim) instead of the sender.

I've pored over the SMTP settings in Windows Server 2003 and I can't figure out a way to fix this. I did find this cool STMP tar pit feature which sounds appropriate -- but unfortunately, will have no effect in my case. As you can see from the above sniffer trace, the basic SMTP service is not smart enough to perfom "recipient filtering"-- to reject email for users that don't exist at the time of submission. The validation of the address occurs after the email delivery process begins, which is too late.

I thought about suppressing non-delivery reports entirely, but this breaks the email protocol:

Some of you might think it would be better to simply turn off recipient filtering, rely on your 3rd party antispam product, and suppress NDRs (as spammers typically use spoofed domains anyway). This is possible but unfortunately doing so breaks RFC 2821, which states that a NDR must be returned if an e-mail message for an invalid recipient is accepted. In addition it also means normal users that perhaps make a typo in an e-mail address will never receive an NDR informing them of the issue.

What I really need is some way to make the default SMTP service in Windows Server 2003 reject emails for invalid recipients prior to accepting the message. That, along with the built-in tarpit support, should break spammers.

I hate to buy a commercial mail server to replace the simple STMP and POP3 services provided with Windows Server 2003. But unless I can stem the tide of SMTP non-delivery report spam, I guess I'll have to.

A colleague forwarded this perplexing dialog to me:

Quite the catch-22. I guess the only thing to do is try something else:

A strange game. The only winning move is not to play. How about a nice game of chess?

This article on AMD's upcoming CPU support for hardware virtualization has the best description of virtualization I've read to date:

In a modern-day virtualization system, a thin layer of software, called the virtual machine manager or hypervisor (both terms are common) runs on the processor. The VMM creates a number of virtual machines, into which it loads a standard, unmodified operating system, such as Linux, Solaris, or Windows.

Each virtual machine thinks it's running on the bare metal, and has the computer entirely to itself. However, the VMM is constantly monitoring the execution of the virtual machines, interceding to redirect memory, storage and I/O requests to the specific allocated resources (think of paging, as an example), and emulating hardware interrupts that might let the software running within one virtual machine affect what's happening in another virtual machine, or even compromise the stability of the VMM itself. This software emulation includes, by the way, rewriting instructions, substituting instructions, changing calling parameters -- there's a lot of stuff going on behind the scenes at the virtual machine manager level.

Evidently the x86 architecture is not well suited to virtualization because it doesn't meet something called the Popek and Goldeberg virtualization requirements. There are a number of problematic x86 instructions that require software interception and translation, eg, emulation:

All modern operating systems expect that their kernel and driver code is running in [Ring 0] privileged mode, which of course is fine in a non-virtualized PC. However, in a virtual machine, you don't want that kernel and driver code, or the interrupt handlers, to really have full control over the hardware; you need the VMM to be able to be able to transparently manage the system. But because both the VMM itself, and the virtualized guest operating system kernel and drivers are running in Ring 0 -- in other words, they're peers -- the VMM has to do a lot of work to maintain control of the guest operating system. Thus, the emulation, and the performance hit that it represents.

How can we avoid this emulation penalty with hardware? Enter the dramatic, mysterious Ring Negative One:

That's where [hardware virtualization support] comes in. It comprises a set of instructions and architectural constructs that solve several of the thorniest problems in VMM software emulation of things like IO calls or interrupt handling. In effect, they create a superprivileged mode (sometimes referred to as "Ring -1"), which can only be used by the VMM. Because virtual machines and guest operating systems and applications continue to use traditional privileged and user modes, the VMM now has unique abilities to control the execution of virtual machine code running in Ring 0 -- without software emulation.

Intel is already shipping a number of CPUs that support hardware virtualization. Future versions may even allow you to hot-swap CPUs and memory:

Intel is working on a version of "Vanderpool" code named "Silvervale" for Xeon and Itanium server platforms. "Silvervale" differs from "Vanderpool" in terms of mission critical requirements such as hot-plug options as well as ability to change memory modules or even microprocessors on the fly, without shutting down the server.

AMD will follow suit with CPUs that have virtualization support later this year.

I firmly believe that, in the not too distant future, we'll always be running in a virtual machine. Hardware support for faster x86 virtualization is yet another important step in that direction.

Aside: I was going to title this post "Ring -1", but when I searched for that term in Google, I belatedly realized I was being stymied by something I just wrote about: dashes are treated as word seperators. As far as I can tell, it's impossible to search for the phrase "Ring -1" in Google.

In Never design what you can steal, I praised this amusing guerilla redesign of Jakob Neilsen's useit.com-- which is widely derided by the design community for its radically bare-bones layout.

Well, the design guerillas are at it again. This time, they've set their design eye on Craigslist:

Original	Redesign
Original	Redesign

I like the redesign. It feels more usable, better organized, and less cluttered. Heck, it even uses sparklines. But I can't get over the nagging feeling that redesigning craigslist is a waste of time. Joel Spolsky elaborates:

But there's a scary element of truth to [Napster's hideous user interface] -- scary to UI professionals, at least: an application that does something really great that people really want to do can be pathetically unusable, and it will still be a hit. And an application can be the easiest thing in the world to use, but if it doesn't do anything anybody wants, it will flop. UI consultants are constantly on the defensive, working up improbable ROI formulas about the return on investment clients will get from their $75,000 usability project, precisely because usability is perceived as "optional," and the scary thing is, in a lot of cases, it is. In a lot of cases. The CNN website has nothing to be gained from a usability consultant. I'll go out on a limb and say that there is not a single content-based website online that would gain even one dollar in revenue by improving usability, because content-based websites (by which I mean, websites that are not also applications) are already so damn usable.

Craigslist is the very definition of a content-based website. The content is such a strong attraction that you could probably change the stylesheet to use green text on a red background and usage would still continue to climb. The redesign is clearly a small improvement, but it's just a statistical rounding error next to the value of the content.

And that's why, sometimes, 'ghetto' is a valid design choice:

[MySpace] empowers people to get their message out and make connections. That's the only way I can put it. Same reason why Xanga, FaceBook and LiveJournal are crazy popular. Get a community together where people can communicate easily and you have yourself a winner. Ask Amazon.

Besides all of that, [the MySpace] site sucks and I never use it, but I know that doesn't matter much when I can enter a club and the first question out of a woman's mouth is "Are you on MySpace?"*

Happens more times then you would think...

Someone we know at a venture capital firm once said he'll only fund for two reasons: if it gets you laid, or it gets you paid. Design is important, but content is king. Make sure you set your priorities appropriately.

James Bach responded to my recent post, Are You Following the Instructions on the Paint Can?, with Studying Jeff Atwood's Paint Can.

Being under Bach's intensive analytical microscope feels a lot like an interview with Hannibal Lecter. It's flattering, but it's also a little scary. You learn a tremendous number of things about yourself – at the risk of your professional dignity, and maybe even your soul.

In a previous entry, I complained about the fact that Bach's blog doesn't allow comments. Some readers took this as a personal attack on James. Nothing could be further from the truth. I've been meaning to write about that topic for months, and James' blog just happened to be the most recent case. I have tremendous respect for Bach and the way he aggressively questions convention. Prior to this paint can dialog, I had already based two blog entries on his writing: It's Better Than Nothing and Best Practices and Puffer Fish. If anything, we should form a mutual admiration society.

Now that I've gotten all the disclaimers out of the way, I can respond to the actual content of Mr. Bach's entry. First, I want to give James credit for identifying a key assumption:

"What I find particularly interesting is that none of the mistakes on this checklist have anything to do with my skill as a painter."

I think what Jeff meant to say [here] is that they have nothing to do with what he recognizes as his skill as a painter. I would recognize these mistakes, assuming for the moment that they are mistakes, as being strongly related to his painting skill. Perhaps since I don't have any painting skill, it's easier for me to see it than for him. Or maybe he means something different by the idea of skill than I do. (I think skill is an improvable ability to do something) Either way, there's nothing slam dunk obvious about his point. I don't see how it can be just a matter of "read the instructions stupid."

This is dead on. I used to run a painting business in college. So my idea of "painting skill" – for the record, it's how cleanly and evenly you physically apply a coat of paint to the surface – is quite different than James'. If you read any of his writing, you'll quickly determine Mr. Bach is incredibly effective at sussing out all the assumptions you're making that you don't realize you're making. And questioning assumptions is a tremendously powerful method of investigation, particularly when someone helps you identify the ones that you're blind to.

Beyond that, the general thrust of Bach's reply is that instructions aren't always helpful:

Consider all the instructions you encounter and do not read. Consider the software you install without reading the "quickstart" guide. Consider the clickwrap licenses you don't read, or the rental cars you drive without ever consulting the drivers manual in states where you have not studied the local driving laws. Consider the doors marked push that you pull upon. Consider the shampoo bottle that says "wash, rinse, repeat." Well, I have news for the people who make Prell: I don't repeat. Did you hear me? I don't repeat.

I would have to say that most instructions I come across are unimportant and some are harmful. Most instructions I get about software development process, I would say, would be harmful if I believed them and followed them. Most software process instructions I encounter are fairy tales, both in the sense of being made up and in the sense of being cartoonish. Some things that look like instructions, such as "do not try this at home" or "take out the safety card and follow along," are not properly instructions at all, they are really just ritual phrases uttered to dispel the evil spirits of legal liability. Other things that really are instructions are too vague to follow, such as "use common sense" or "be creative" or "follow the instructions."

There are, of course, instructions I could cite that have been helpful to me. I saw a sign over a copy room that said "Do not use three hole paper in this copy machine... unless you want it to jam." and one next to it that said "Do not use the Microwave oven while making copies... unless you want the fuse to blow." I often find instructions useful when putting furniture together; and I find signs at airports generally useful, even though I have occasionally been steered wrong.

Instructions can be useful, or useless, or something in between. Therefore, I propose that we each develop a skill: the skill of knowing when, where, why and how to follow instructions in specific contexts. Also, let's develop the skill of giving instructions.

Although I absolutely agree that you must be critical of everything you read, James' statement that "instructions can be useful, useless, or something in between" is just as unhelpful as my "for best results, follow the instructions" advice. I implicitly assumed that the person reading the instructions on the paint can was smart enough to read those instructions as suggestions, reminders, and guidelines – not as a recipe to be slavishly followed to the letter.

I agree with Bach's assertion that a paint can is neither a supervisor, nor a mentor, nor a judge of quality. A static list of instructions is no substitute for hands-on help with your painting project from someone who has extensive painting experience.

But you rarely have the luxury of working with experts. Most of the time, you're on your own, and the bulleted list is all you have. Consider this list of painting tips from John Montgomery. We had a problem a few days ago while painting. Our latex paint was drying exceptionally fast on the second coat and causing problems with the smoothness of the finish. Because I had read John's painting tips, I remembered this bullet point from his list:

Mix your paint and add Flotrol. If you're more than 24 hours from the paint store, open your paint and mix it. You should also add Flotrol (latex) or Penetrol (oil) to it – these paint conditioners don't thin the paint or change its color, but they do affect how smoothly it goes on and limit brush and roller stroke evidence.

I went to the store, bought some Flotrol, mixed it in, and our problem was solved.

It's doubtful I would have been able to fix this problem if I hadn't followed at least some of the instructions on John's blog. Although I agree with James Bach's central point – you should question everything you read – I sort of assumed everyone does this already. Maybe I assume too much. But sometimes a bulleted list of instructions sure does come in handy.