Category Archives: Musings

Pace this ZDNet story, which describes how MessageOne has seen a spike in workload with the unwanted arrival of Katrina in the New Orleans-Biloxi-Gulfport-Pensacola strip. The article makes an excellent point: the time to get a recovery or continuance solution in place is before the bad weather starts. Just like flood insurance, if you wait too long you won’t be able to get protection in time.

All I can say is “wow!” There are a ton of new features and enhancements– very impressive for a point release. Please let me know if you find anything that doesn’t work properly.

Steve Friedl just posted the first public draft of “An Illustrated Guide to IPsec“. It’s very well done, with lots of illustrations that help explain how IPsec works. It will help if you already know the basics of IPsec, but there’s a good bit of intro-level information for those who aren’t already IPsec gurus.

Wonderful news: Microsoft’s Jesper Johansson is blogging. (You may remember him as the guy who said it’s OK to write down passwords). Check it.

Microsoft is making a “community technology preview” (CTP) of Exchange Server 2003 service pack 2. This is pretty cool. Get it from this link (which should be live shortly). I’m particularly interested to see how people put the Sender ID tools to use.
Update: the Exchange team blog has a list of FAQs about the CTP. Note well that the CTP build isn’t supported by PSS and shouldn’t be run on production servers.

Great news: CIS has finally released their benchmark for Exchange 2003. It’s a fairly comprehensive assessment and hardening guide for Exchange Server 2003 (see these FAQs for more details). It was developed by CIS with input from NSA, MITRE, Microsoft, and various parts of the Exchange community. I think it will be of great benefit to most organizations now running Exchange (of course, I should have asked them to include the book in the bibliography 🙂 )

Devin Ganger, my cow-orker at 3sharp and coauthor of the Exchange Server Cookbook, is on the scoreboard again– this time with an ebook on discovery, compliance, archival, and retention. The first chapter‘s now available, so go check it out.

I’ve been asked several times about ways to disable the use of removable storage devices to protect against pod slurping and related attacks. XP SP2 has a way to prevent writing to USB devices, but there’s another solution that’s described in this MVP-contributed KB article.

From an article I’m working on, the difference between high availability and business continuance succinctly expressed:

Availability measures how much use we get out of a system before it fails, or between failures. Business continuance (BC) is different; it means being able to continue business operations (possibly with some degraded capacity) while a recovery operation is in progress. A simple example might help: if your building has an automatic emergency generator, that’s HA. If you have to bring in your own generator from home, that’s BC.

Last year, I wrote about US v. Councilman, a court case in which the initial ruling seemed to indicate that it was OK to intercept others’ email under certain conditions. Yesterday the First Circuit Court of Appeals issued a new ruling, essentially reversing the old one. Councilman was indicted in 2001 for violating the US federal law covering wiretapping because he was using procmail to copy inbound messages to hosted users on his server. The case was originally dismissed based on Councilman’s claim that the messages he copied were in “electronic storage” (which has a narrow meaning under the 1968 wiretap law), and that what he did wasn’t technically “interception” as defined in the law. The government appealed, and now the Court of Appeals is siding with them. Read their ruling for yourself; after I have time to dig into it a bit more, I’ll have more to say (bearing in mind, of course, that I’m not a lawyer and don’t give legal advice.)

Finally! Microsoft’s released Microsoft Messenger:mac 5.0, which can use both the MSN Messenger service and Live Communications Server 2005. It fully supports TLS and Kerberos (although you’ll need to read this reskit paper to turn Kerberos on). It also supports PIC for LCS if you’re using it. In my tests over the last few months, I’ve found it very stable. It just works. If you’re using a Mac, give it a try. (now, if we could only get a new version of the suck-a-delic Windows Media Player for Mac…)

See above: how much would you pay for a solution that actively prevents people from using “reply-all” to mass-distribution mails? (RMS does lots of other neat stuff, too, that I’ll be writing about in the future.)

Here’s an interesting tidbit: Scalix announced today that they’re going to ship a wireless solution for their messaging product, based on Notify‘s product. Pricing and availability weren’t announced; from a functionality standpoint, Notify has a pretty nice solution in terms of the range of devices and OTA methods they support. However, this may add significantly to Scalix’ “flyaway” cost, making them potentially less attractive compared to Exchange 2003. No word yet either on whether Scalix will require device or mobile CALs in addition to mailbox CALs. Developing…

Bruce Schneier is a smart guy, but he also has a strong anti-Microsoft bias. That’s why it’s no surprise to see this article, in which he lambasts Microsoft for “building in security bypasses”. What’s he talking about? A quote from Microsoft’s Martin Taylor:

For example, this new feature tool we have would allow me to tunnel directly using HTTP into my corporate Exchange server without having to go through the whole VPN (virtual private network) process, bypassing the need to use a smart card. It’s such a huge time-saver, for me at least, compared to how long it takes me now.

Of course, that’s our friend RPC-over-HTTPS. I think Schneier missed the point because he misunderstands the intent of the feature, which is to allow mail-only access from remote systems. It’s true that VPNs allow for secure remote access to many different types of resource, often using multi-factor authentication. It’s also true that many VPN systems (particularly the clients) are unstable and difficult to use, particularly from locations like hotels and airports where the network provider may not be clueful. The RPC tunneling feature allows secure access to email only without a VPN. This is actually a security benefit.

Why? Think of what happens when you connect a remote computer via VPN: you’re allowing it unrestricted access to your entire corporate network. That means that when Joe Executive‘s home machine connects via VPN it has free roam of the network. That places a mighty high premium on ensuring that the remote machine is uncompromised, hence the interest in network access protection (but that’s a solution for another day). As an admin, if I have users who only need email, I’m perfectly happy for them to use RPC-over-HTTPS instead of VPN because then I know that their machines are very unlikely to be able to cause damage to other machines on my intranet, no matter how crap-infested they may be. Couple RPC tunneling with an application-layer RPC scanner (like the one in ISA Server 2004) and you’re better off than you would be with a pure VPN solution.

Some of the comments on Schneier’s post make good points about the tradeoff between usability and security, including one guy who asks why VPNs are so hard to use. That’s for another post, unfortunately.