I wrote about Melissa on the Monday after the worst of it. A week later I have had conversations with three different mail administrators who spent that weekend in the office, and a clearer picture of what changed in real organisations is starting to form.
The headline story is the loud one: "the worst worm in history; mail servers down; emergency advisories issued". That story is true but incomplete. The smaller story — the actual operational changes that stuck — is more interesting.
What admins actually did
Three organisations of three different sizes, all with similar shapes of response.
The financial-services place had thirty thousand inboxes. They were briefly underwater on Friday afternoon. By Saturday morning they had pushed an antivirus signature update through their corporate distribution and instructed users not to open attachments. By Monday, normal operations had resumed. The lasting change: a hard policy that all incoming attachments are scanned by the AV gateway before they reach the user's inbox. This was not in place before Melissa. It is now mandatory.
The university, with about three thousand staff and twenty thousand students, was hit hardest because their architecture had no central scanning. Mail flowed directly from edge SMTP to per-department mailboxes, with no in-line filtering. The lasting change: a central mail relay through which all mail now passes, and a policy decision to fund and staff that relay as a permanent service. This is a structural change, not a technical one. It is, I think, the most significant of the three.
The small consultancy, with about a hundred staff, was barely affected. They run Linux mail servers, which Melissa cannot directly damage; they had no Outlook on the server side; their staff use mail clients that do not auto-execute attachments; and their existing procmail rules already stripped Word attachments at the gateway. They were quietly smug all weekend.
The pattern across all three: the things that helped were structural decisions made years ago, and the things that needed fixing afterwards were not specific to Melissa but general to the architectural assumption that mail content was safe.
The assumption that died this week
Until this week, mail attachments were treated by most operators as data. They flowed through the system like text would: filtered for viruses if you happened to have a scanner, but otherwise just bytes-on-the-wire. The mail server's job was to deliver; the desktop's job was to render; whose job was to keep them safe was a question that did not have a settled answer.
Melissa has settled it. Mail attachments are executable code until proven otherwise. The mail server, the perimeter relay, and the gateway scanner are all now in the position of having to make a decision: pass through, scan, strip, or refuse.
This sounds obvious in hindsight. It was not obvious last month. The default setting in every mail product on the market last month was "pass through, optionally with scanning". By the time the next major mail product is released, the default will be "scan; strip if uncertain".
The macro security model
The deeper problem Melissa exploited was not in mail. It was in Word's macro security model.
Microsoft's response to Melissa includes — among other things — a Word patch that requires user confirmation before running macros from documents that are not from "trusted sources". The trusted-sources mechanism is rough and badly explained, and most users will either disable it or accept everything as trusted, which defeats it. But the architectural shift it represents is meaningful.
Macros, until now, ran by default in any document opened by Word. The principle was that documents and applications were on the same trust footing — your documents were yours, you wrote them, why would you not trust them?
Melissa proved that the principle, while satisfying, does not survive contact with the actual document distribution mechanism. Documents come from email. Email comes from anywhere. "Document" is therefore, in practice, a foreign-trust object. The macros that ride along with documents must inherit foreign trust until something proves otherwise.
This is the same epistemic shift the web went through with client-side scripts a few years ago — JavaScript is now sandboxed, restricted, and treated as foreign by default in every browser. The transition for documents has barely begun. Melissa is the moment when the transition got pushed forward by about five years of normal development.
What I am taking from this
Three things, to keep in mind for the next time.
The defaults of widely-deployed software are themselves a security architecture. Decisions made in Redmond and Cupertino about what runs by default on millions of desktops are decisions with system-wide effect. They cannot be reversed quickly. They are, in practice, more important than what any individual operator does.
Operationally, mail filtering is a real engineering discipline. Not a checkbox in your AV product. A filtering relay, with rules, with logging, with a way to add new patterns under pressure, run by a team that knows what is in the SMTP RFCs. The places that survived Melissa best had this. The places that suffered most did not.
Pre-existing structural choices matter more than incident-response speed. All three organisations I spoke to had Melissa under control within 72 hours. The difference between them was not the response — they were all good at responding. The difference was what they had in place before the response was needed. The university paid the most, not because their team was bad, but because their architecture had no chokepoint at which to apply pressure.
The specific problem this week was a Word macro. The general problem this week was that mail and document handling were architected for an internet that does not exist any more. Fixing this properly is a long project, and Melissa is the prologue.