I had a funny experience yesterday.

I don’t typically use Microsoft Outlook with my home email account. But it was bundled with the copy of Office 2010 that I installed a few months ago, and I figured: heck, if I have it anyway I might as well hook it up to my personal IMAP account. So I configured Outlook, played with it a bit, then promptly forgot all about it.

Fast forward to yesterday evening. I launch my copy of Outlook for the first time in months in order to try something with the calendar, but then I get distracted and walk away from the computer. Five minutes later my cell phone gets a message from my FreeBSD server:

EMAIL SERVER HIJACKED - FIREWALLING POSTFIX

Oh. Fun.

A slight digression before I can get on with the story: I try my very best to be a good Internet citizen, and that of course means not allowing oneself to become a spam relay. Because this email server exists only for my personal use, it was simple to write a Perl script that monitors my Postfix logs and, if it sees anything grossly out of the ordinary sent out through the server, reconfigures PF to block outbound connections to TCP port 25. It seemed the responsible thing to do, especially since some PHP applications on my web server have permission to relay through this Postfix instance; and let’s face it, WordPress has a less than stellar security track record.

This script has never given me a false positive. So this was definitely cause for concern.

I shelled into my VPS and went straight for the mail logs. I was dismayed to find more than twenty entries like this:

Dec  8 23:35:38 frodo postfix/smtpd[13146]: 13DB43F4DC: \
    client=redacted[xxx.xxx.xxx.xxx], sasl_method=LOGIN, sasl_username=redacted
Dec  8 23:35:39 frodo postfix/cleanup[13148]: 13DB43F4DC: \
    replace: header Received: from noatun (redacted [xxx.xxx.xxx.xxx]) \
(Authenticated sender: redacted)
by frodo.paleogene.net (Postfix) with ESMTPSA id 13DB43F4DC
for <redacted@example from redacted[xxx.xxx.xxx.xxx]; \
    from=<redacted@example.com> to=<redacted@example.com> \
    proto=ESMTP helo=<noatun>: Received: from auth-client.paleogene.net \
    (auth-client.paleogene.net [206.125.175.178])
(Authenticated sender: hidden)
by frodo.paleogene.net (Postfix) with ESMTPSA id 13DB43F4DC
for <redacted@example.com>; Wed,  8 Dec 2010 23:35:37 -0500 (EST)

All of them sent within seconds of one another, and all of them to random Gmail accounts and other recipients that I absolutely did not recognize. Worse, the messages had been sent through a properly SASL authenticated connection from my laptop (HELO noatun). To quote that old horror flick: They’re coming from inside the house!

I’ve heard tell of Windows viruses that will quietly send spam through the user’s configured Outlook mail account, so that the messages originate from a legitimate mail server and have a better chance of skipping recipients’ spam folders. I have no idea whether this is actually a common occurrence in the real world, but it’s plausible enough, and I couldn’t think of any better explanation why 24 messages had been sent out from my computer in a matter of seconds, all to recipients I’d never heard of. I still could not fathom how a spam bot might have made its way onto my laptop despite my precautions, but better safe than sorry…

Process Explorer and TCPView failed to reveal anything suspicious, so I shut down the laptop, yanked out its hard drive, hooked that up to another machine via a USB-SATA adapter, and started a full offline virus scan.

Meanwhile I kept poking around on the mail server. I had a bit of luck when I checked /var/spool/postfix/deferred — a few messages had been caught in the Postfix outbound queue when my script added its firewall rule. I was morbidly curious what had been sent.

…it was a freaking Message Disposition Notification.

Now sure, I knew all about email read receipts, but I’d immediately ruled them out as the cause of this behavior because all of my email clients, Outlook included, are configured to at least ask my permission before sending one:

[caption id=”attachment_668” align=”aligncenter” width=”570” caption=”Outlook completely ignores this”][/caption]

And anyway, I hadn’t read or deleted any email messages in Outlook, so why would it want to send any MDNs in the first place?

I did some googling and the pieces slowly began falling into place. It turns out there’s a horrific bug in recent Outlook versions’ handling of read receipts: unread messages deleted from an IMAP folder can send a “not read” MDN, even if you’ve explicitly configured Outlook not to do so.

And as I had just discovered, it isn’t even necessary to delete the messages from within Outlook itself to trigger this behavior. Months ago when I set up Outlook for my IMAP account, I was subscribed to several Debian and other technical mailing lists that I’ve since left (these days I prefer to use the Gmane NNTP gateway to read such lists). Apparently when Outlook started up and noticed that these lists’ mail folders no longer existed on my server, it decided to send a “not read” notification for each unread message that requested one in Outlook’s old cached copy of the folders.

Some searching of the mailing list archives confirmed my hypothesis. Every recipient of one of these mystery messages had posted something to one of these lists, presumably (probably unknowingly) including a Disposition-Notification-To: header in their posts.

I can’t find the words to describe just how wrongheaded this behavior is. Not only is it semantically incorrect — how can Outlook assume that just because a message has been deleted from the IMAP server, it wasn’t first read in some other mail client before being purged? — but it’s a horrendous privacy risk too, and a boon to email address harvesters.

And in this case, it led me to waste two hours of my time as I had to diagnose this unsolicited, seemingly spam bot-like burst of messages that went out through my server.

As much as it has improved over the years, I think this proves Outlook 2010 is still entirely untrustworthy as an email client. Avoid using it if at all possible.

Ars Technica has a four-part introductory series on logic and argumentation, entitled “Getting to QED.”

In some cases, there is a way to tell good arguments from bad using what is called informal logic. This name distinguishes it from formal logic, which is used in mathematics; natural language is less precise than mathematics, and does not always follow the same rules. Perhaps more surprisingly, the name also reflects the fact that there is a lot of disagreement over what it means. Informal logic is actually a fairly young discipline, developed in the 1960s, and intended to apply new techniques from formal logic to argument and critical thinking. Philosophers are still wrestling with this application, and there are several competing schools of thought.

For all the differences, there are some core elements upon which everyone agrees. This article is a tutorial introducing these basic ideas of informal logic. In particular, we focus on deductive reasoning, which is one of the cornerstones of analytical thought. Hopefully you will come away from this article with the tools to distinguish a productive debate from an acrimonious flame war.

This should be required reading for anyone who’s engaged in debate on a mailing list or web forum.

This guy is the best kind of crazy…

How am I just finding this now? He’s made major progress since filming that video; check out his YouTube channel for more. Seriously man, thumbs up…

I’m posting this here so I can find it again later, because this one caused a surplus of annoyance before I finally found a solution…

I have a Windows 7 x64 laptop which would randomly (once or twice a week) set the NTFS “dirty” bit on its C: drive, causing chkdsk to run at boot and find… well, no problem whatsoever. Sometimes this glitch would be heralded by a system tray / notification area message that the filesystem was allegedly corrupt, but often there would be no warning (aside from NTFS Event 55 messages in the system event log, or the output of

fsutil dirty query c:

if I bothered to run it manually), until chkdsk began its long run the next time I restarted the computer. Yeah, I know I could have used

chkntfs /x c:

to stop boot-time filesystem checks altogether, but then if there actually were a legitimate problem one day… :)

Anyway, after a couple months of this I finally hit upon this discussion on Microsoft TechNet, which in turn led me to KB 982927, including a hotfix (Fix316593). Microsoft makes you jump through some hoops to get the hotfix (you have to do an email confirmation thing and then even the download is password protected — why?), but after a month and a half I can say this has completely resolved the problem for me with no ill effects.

Hopefully Microsoft will roll this into SP1, since this is a longstanding, seemingly widespread problem, but at least we have this in the meantime…

Gtk2hs is my favorite way to do cross-platform GUI programming in Haskell — and it’s the toolkit to use if you want to work through the examples in the excellent *Real World Haskell*. But the official instructions for building gtk2hs on Windows leave out some important information, so here’s how I got it all working on Windows 7…

pkg-config.exe --modversion gtk+-2.0

cabal update
cabal install gtk2hs-buildtools
cabal install gtk

ghc.exe --make Hello.hs -o Hello

I wrote a little old-school Windows HTA script to delete the .DS_Store, .Trashes, and ._* junk files and directories typically littered across non-HFS media by Mac OS X:

You can download it from my GitHub account if you have a use for this sort of thing. Written and tested with Windows 7 and IE 8; I’m not sure how it will work with earlier versions of either. Standard disclaimers apply: use at your own risk, etc.

Incidentally, I think HTAs are really underrated as Windows scripting goes. More on that topic later…