Ask Slashdot: Self-Hosted Gmail Alternatives?
It's ironic for me that you should post this on the day after I just abandoned my last home-maintained mail server in favour of Google.
For the past 15 years I've been a mail administrator in some capacity for a variety of mail systems ranging from my own personal colo to a vast multi-national corporation. Solving the technical problems of building and maintaining a functional and reliable system was fun for a number of years, especially when email was dominated by geeks. But nowadays, running your own server is a perpetual nightmare.
First, there's the problem of where to host it. It has to be accessible wherever you are, and it has to be able to send mail out. If you're planning on hosting it at home, on the end of a cable/DSL/fios connection, bear in mind that your IP address will almost certainly be blackhole listed. Also, your ISP may well be blocking outgoing mail to prevent spam. You will probably have to configure your system to route all out going mail via your ISP's SMTP server. Why are you hosting an SMTP server again?
If you're hosting it in a nice VM or in a colo, you're better off, but paying. Google costs you nothing.
Next, storage. Obviously that's no problem because you have a mirrored RAID eleventy-five array you built yourself. If that's in the colo then you can forget about it - except when a drive goes bad or it crashes unexpectedly. But then it's fine because you're paying for support aren't you. And backups. You are backing it up aren't you?
Next the server software. Personally I've had a lot of success with Sendmail/Cyrus IMAP/IMSP/Squirrelmail and friends, despite enduring jeers from other sysadmins who think they have a better combination. In the end, it doesn't matter. They all suck. They all need patching regularly. They all break. They all need tweaking on a regular basis.
Then the final turd in the swimming-pool: spam. It costs you so, so much; bandwidth, around 95% of all of the inbound traffic is spam; time, configuring and maintaining spamassassin and various blackhole lists that occasionally start rejecting mail indescriminately; pride, the only time your clients contact you will be to ask why the mail is so slow and why there's so much spam. "But my gmail doesn't get this much spam - can't you filter it" they say, while you bite chunks out of your tongue. Spam to a mail administrator is like the gopher in Caddyshack: it will keep you awake and turn you into a monster. And the day will come where you, spam-slayer and junk-mail terminator, get put on a blackhole list for being a spammer. That's really fucking harsh the first time.
I could go on. but we're already in the TL;DR territory.
Most people do not host their own mail server. They live longer and healthier lives as a result. Follow their example and let Google worry about all of that for you - and in return you just have to pay them...nothing.
Strong Passwords Not As Good As You Think
You don't need to be "hacked" to have a keylogger attached mr boatman (or may I call you sweaty?) You just need someone to get a job as a janitor (see the relevant article in 2600). Keyloggers come in hardware these days, and that includes the last 15 years. That's where stuff like OTP and friends come in.
And as for password aging, our friend below is not alone in writing his passwords down. If people have "secure" passwords generated weekly/monthly/daily they're going to put them on post-it notes. If people have memorable passwords that are secure against a dictionary attack (it's possible my friend) then that's as much as you can do. Oh yeah you can ask "Doreen from accounts" to use KeePass to store her passwords, but it would be far simpler to go for a big piss in the wind.
Linux in a Business - Got Root?
OK - end users fair enough, but what about the users who *manage* the box ?
At my last job the audit procedure was totally mental. An example:
We were the engineering team for the global email backbone (around 90 servers). Our software and scripts run on all of these servers (as root in many cases). But we weren't allowed root access, so we couldn't install any thing or even debug live systems properly. That was the job of our "ops" team. We package the software, they deploy it. Any problems, they tell us and we have to fix it and redeploy it. Even though our ops team had root, they couldn't just login and do things that needed doing. They needed to file a change request - which took a week and had to be approved by about 10 people.
Despite having root they couldn't just do what they wanted. Every su was logged to a database and they had to give reasons for every one. And as for adding users, modifying system files, fixing permissions....nope - that was the job of the SAs!
So, when a problem occured on a production box, rather than logging in, suing and fixing it, the procedure was as follows:
- I notice the problem.
- I send an IM to my boss.
- My boss organises a group IM chat to discuss the issue.
- The result of the chat is that the "SA team" need to be contacted as none of us are allowed to login to the server (for corporate reasons).
- The boss asks someone to page the team and to setup a conference call.
- A conference call is established with 7 people, all in different countries, and we spend a while waiting for the SA team to respond to the page.
- Eventually the guy arrives and we try to diagnose the problem by telling the guy (who, despite being very well meaning and competent, doesn't speak very good english or have a very good understanding of the systems involved at all.)
- We realise that the only way we're going to solve it is by getting a login into the affected server.
- We try to describe the measures necessary to the SA guy to perform this and fail...
- ...loads more tedious crap until we all realise that unless we leave the call we will die there.