Category Archives: Musings

The MS SQL Server 2005 and Visual Studio 2005 teams have a hysterical site called “Escape from Yesterworld” that casts IT development as something out of Flash Gordon. The overall site design is brilliant, and there are some extremely amusing video clips there, including:

• Evil Wears a Cape
• I.T. From Ages Past
• Repetitive Tasks of Doom
• Change Orders of Death
• Terror on Two Wings

Well worth a look– I give it two thumbs up.

Yesterday I wrote about Simon Butler’s quest to prevent individual users from sending messages via MAPI. In related news, the Exchange team blog has a great post today explaining how Exchange 2003 SP2 gives us the ability to block individual users from using MAPI. The good news: because the MAPI blocking is added to the existing ProtocolSettings mechanism for blocking other protocols, you can use the same script to block or allow multiple protocols at once. The bad news: as with Simon’s original question, this method doesn’t stop existing connections; it only blocks new ones. Still, this is a valuable new capability to have.

Wow, this article made my head hurt. David Berlind of ZDNet documented all the stuff he had to do to get his XV6600 to work via Bluetooth as a modem for his laptop. I admit that I never bothered to try this while I had a loaner XV6600, fearing that it would be too hard to be worthwhile. Here’s Berlind’s conclusion:

OK, now that we’re done, and some of you now have the best step by step you’ll ever find for getting a DUN connection working with Bluetooth, what does it tell you that takes nearly 40 distinctly separate screen shots or photos to document something that should be a lot simpler?

It tells me that I’m sticking with my aircard, thankyouverymuch.

Exchange MVP Simon Butler posed what seems like a simple question: how do you stop a user from sending mail? The answer is deceptively complex; we’ve been debating this on an MVP list for a few days now.

Say you have a MAPI user. You disable the associated Active Directory account, either by disabling the account or by changing the password. In either case, the user can still submit mail to the information store! In the case of a password change, the user will be asked to authenticate again, but if she cancels the password dialog, she can still send– she just can’t receive new mail! That might be a problem in case of an employee who’s leaving (voluntarily or not), although a measure of physical access control will help.

You can kill the MAPI session, but that doesn’t do anything to stop the user from reconnecting from the client side, at which point you’re back to square 1: the user can still send mail. (This doesn’t seem to be true if the user quits and relaunches the client after you kill their session, though).

For other protocols, it’s easy to prevent users from connecting and sending mail. For example, for IMAP, POP, or HTTP connections, you can just remove the user’s ability to use those protocols by using the Exchange Features tab in AD Users and Computers.

If you want to block all users, you can do that too; KB 288894 describes how to limit MAPI connections to a particular version of Outlook (so just set the regkey to deny from the current version (which I think is 11.0.6352.0) backwards. For HTTP, you can either set an IP address restriction on the Exchange vdir (thanks, KC!) or stop the w3svc, although this will have other effects. For that matter, if you want to prevent all client access, stopping store.exe will do the trick nicely at the cost of a service interruption.

Perhaps MS will fix this in Exchange 12.

I leveraged McDonald’s wireless service when I was in rural Louisiana, but it looks like I’ll have a tougher time getting connected while I’m at Sturgis. The nearest McD locations to Hill City, where we’re staying, are in Rapid City, and none have Wi-Fi. Verizon’s coverage map shows no coverage for Hill City, although the surrounding areas have digital service– hopefully I’ll be able to use my aircard. There’s a local ISP, RapidNet, that may be able to help, too.

Interesting press release this morning from Blue Security, touting their new “Do Not Intrude Registry”. The basic concept is simple: you sign up for their service and install an agent on your local computer. Blue creates honeypot mailboxes, which it then monitors. If spammers spam those mailboxes with messages that don’t comply with the CAN-SPAM law, Blue asks the spammers to stop. If they don’t, the Blue agent (which they call a Blue Frog, after the blue poison arrow frog) starts spamming the spammers by posting junk data to their order form. This is no big deal if only one agent does it– but the agents are cooperative, so if the spammer sends out 10,000 messages, they get 10,000 junk order submissions.

The PR calls this “ethical and effective”. I disagree on both counts; it’s nothing more than a botnet in disguise. If it’s wrong for J. Random Attacker to mount a DDoS against a website they don’t like, it’s wrong for Blue to mount DDoSes against spammers. Despite the fancy language deployed by Blue’s CEO in this InformationWeek article, it’s pretty clear that this is a clear-cut DDoS approach– Blue is trying to hit the spammers where it hurts by degrading their operational capacity to take orders.

I don’t condone spammers, but descending to their level isn’t an ethical approach. In a remarkable coincidence, most of the sentiment on /. seems to agree that this is a bad idea.

Update: but don’t take my word for it; legendary guru John Levine has weighed in with his thoughts (including the interesting fact that Blue tried to get sponsorship from a number of anti-spam orgs, all of whom rejected the idea).

I missed this in all the hubbub here at el rancho, but Alexander Nikolayev posted a terrific treatment of the Exchange 2003 SP2 anti-spam process at the Exchange team blog. He covers how the new SPF/Sender ID filtering process works in conjunction with the existing filtering features. Exchange 2003 SP2 is the only spam filter that Microsoft’s using for their 90,000+ worldwide mailboxes; I think that’s a pretty strong endorsement of its capabilities.

Just got the press release: Microsoft is buying FrontBridge, a hosted message hygiene service provider. This is primarily interesting because of FrontBridge’s strength in compliance solutions; they have a broad range of services built around compliance for email and IM. Their hosted anti-spam services got good props from eWeek, but I think the combination of their data centers (which promise a 99.999% uptime SLA) and their compliance services opens the door for MS to diversify beyond Windows OneCare into a broader scope of direct service provision. I can’t wait to see what part they play in the promised Exchange 12 updates for better compliance and message hygiene.

Unless you read the “Book of SP1” very closely, you might have missed out on the fact that Windows 2003 SP1 enables auditing of metabase object access. The IIS documentation for the feature is of little help, since it’s missing some steps. This can be very handy for Exchange administrators, given how much heavy lifting the IIS core components do. IIS MVP Ken Schaefer has written a simple explanation of how to configure metabase auditing here.

Here’s an interesting development: IBM made a Notes-related acquisition, buying PureEdge. PureEdge makes a set of XML-based forms tools– not too dissimilar from another familiar XML tool, InfoPath. Could it be that IBM is feeling the pain of having a relatively poor XML story in Notes and Domino? Are they trying to play catch-up? Maybe.

Microsoft is widely reported to be preparing a server-based version of InfoPath, which would give them a pretty complete story for form management on the client, the server, and the back-end (via WSS, SPS, and BizTalk). Looks like form-based application development will become another front in the IBM-MS platform battle. I’ll be interested to see how (or if) IBM integrates the new solutions into its products; clearly it’s too late for Domino 7.x, so I’d expect these to be part of a future Workplace technology release in some form.

Ever get tired of trying to explain (or, worse, remember) the difference? Check these handy diagrams: RAID-10 and RAID-0+1.

Update: edited to fix a bad link for the first diagram (thanks, Devin!)

Now I’ve heard everything: this article describes (with a straight face, I’m sure) how to set up a Linux box running VMware to use Postfix as the SMTP front-end and Exchange 5.5 as the mailbox store. Why you’d want to do this is beyond me. For an encore, I hear the author’s going to write an article on how to run Lotus Notes 4.0 on a PlayStation Portable.

John Denker has written a superb essay on why ID “theft” shouldn’t be a problem, and how we already have all the tools to prevent it from being one. Excerpt:

it shouldn’t matter if somebody knows who I am. Suppose somebody can describe me — so what? Suppose somebody knows my date of birth, social security number, and great-great-grandmother’s maiden name — so what?
It’s only a problem if somebody uses that identifying information to spoof the authorization for some transaction.
And that is precisely where the problem lies. Any system that lets identifying information serve as authorization is so nonsensical that it is hardly worth discussing. I don’t know whether to laugh or cry.

He goes on to draw the distinction between entity authenticaiton and transaction authentication, and goes on to propose a couple of schemes for breaking these into two separate mechanisms instead of the conflated mess we now have. Well worth a read for anyone interested in security.