I recently procured and configured a new storage server and knew I wanted a scalable, redundant way of storing the large amount of data this server will hold. Despite what Steve Gibson has said about the so-called hardware RAID on modern motherboards it’s dangerous! It’s not really a hardware solution and requires that the same propriatary chipset be used to recover the data which is a dangerous thing to rely on when it’s your data you need back.

Sidebar: One of these days I’m going to get around to creating a blog or netcast devoted to correcting the misinformation on TWiT and SecurityNow (I understand that it’s difficult for them to stay on top of all this, but speculating on what you don’t understand in front of hundreds of thousands of people who worship the ground you walk on is a poor choice and seems to happen more often that I think is acceptable). They need a technical editor and fact-checker and since they apprently aren’t doing it in house someone else should.

Anyway, with modern processing power there’s little reason to use hardware RAID in a much other than a large corporate environment (or if you like spending a good sized chunk of money). I’ve had good luck with the Linux mdadm software RAID and have actually been impressed with how well it works. What I have not done is to utilize LVM (logical volume manager) to make it a more scalable solution where drive size can be increased or drives added down the road.

In preparation for this configuration I read a great howto on the topic which you can find on the JerryWeb Wiki. Things went quite smoothly and I’ve been very happy with the configuration so far which includes four SATA II drives (with working hot-swap capability in a drive cage) in a RAID 5 array. As soon as I get another AHCI SATA controller in I’m going to be adding another drive to the array so we’ll see how easy the LVM makes that!

For quite some time now I’ve been running my own Linux (Debian w/ Postfix) mailservers. For the past several years I’ve had good luck basing my installations on the fantastic instructions available at workaround.org but this summer even these systems were failing to filter a lot of my spam. Naturally, I went looking for other anti-spam technologies I could add.

For a few years now I’ve published SPF records for my domains and I’m a strong believer that wider implementation of SPF would greatly reduce the amount of spam using forged addresses. Anyway even though I had been publishing SPF records I had not gotten around to implementing SPF checks on my own server so this was one thing I was looking for.

Another was that I had heard a little bit about something called greylisting. Greylisting is a process by which mail from unknown senders is initially bounced with a “service temporairly unavailable” message but when the remote server tries a second time after waiting some period the message is allowed through. This works on the premise that real mail servers which comply with the mail RFCs will keep retrying to send a message until it goes through or a hold timer expires (usually several days) but spamming programs (often trojans on unsuspecting users’ systems) will only try once. Obviously this won’t stop all spam, especially that from legitimate companies using legitimate spam servers and it could easily be bypassed by the trojan writers by trying to send a message several times. I beleive the latter has not happened because of the additional processing overhead this would create and so far it’s simply not efficient for spammers to track all this.

Eventually I settled on implementing both SPF checking and greylisting based on this guide. The guide actually contains a full howto on setting up a Debian/Postfix mailserver similar to the workaround.org guide I mentioned before. I have only briefly glanced at this other information as I already had a working mailserver but I can say that the method they propose is quite similar, but not entirely the same as the workaround.org method.

Since implementing these changes my own mailserver has been rejecting much more spam (without any increas in false positives) than before. When I temporairly turned this off to migrate to a new mailserver I immediately saw a marked increase in spam getting through. While I have not tested it extensively it is my belief that more is being stopped by the greylisting than the SPF, mostly because many domains do not yet publish SPF records (though several large ISPs which are commonly spoofed now do).