How to set up a mail server on a GNU / Linux system
flurdy.com
flurdy.com
I enjoyed "The Five Stages of Hosting" posted earlier (http://news.ycombinator.com/item?id=3526767). In that metaphor, Google Apps is the large, modern and comfortable house in a central location with most amenities and virtually rent free - only downside is that the landlord won't let you knock down the walls, and there's no way a grand piano will fit through the front door.
Also Google Apps broke on me and their support is absolutely utterly useless.
And when something gets blacklisted, TSHTF. It's much easier to sort it out yourself.
Actually, the Google Docs integration is probably the biggie.
Re: Calendar I've done two calendar technology migrations for 500+ person companies - they are typically forklift upgrades done over a weekend. You basically lock in your resources (rooms, typically) a week ahead of time, have people rebook any forward meetings into those resources - and have everyone switch into the new system on Monday. As long as people have the right client (in Googles case, that would be a "Web Browser") there is no lock-in.
I could take a 500 person company from Google Calendar, Email, and Contacts over to Microsoft exchange with a team of three people in under a month, with maybe 2 days of disarray (monday) as people (who ignore instructions the previous week) update the mail servers and LDAP servers on their various Androids, iPhones, Macintoshes, etc...
Just make sure you keep your primary directory in your own LDAP server, and you will be good to go. Don't outsource the directory. And stick to something LDAP compatible.
Then again, the user experience with the leading alternative solution (MS Exchange) is so miserable that at one organization I'm aware of, the public announcement of a migration to Google Apps for Domains was greeted with a standing ovation.
Another interesting factoid: Hal Varian, co-author of Information Rules, which largely discusses strategic use of lock-in by both vendors and users, is Google's chief economist. I suspect this is a subject the organization understands well: http://www.amazon.com/Information-Rules-Strategic-Network-Ec... http://en.wikipedia.org/wiki/Hal_Varian
I disagree with the metaphor of the landlord reading your mail: As slightly worrisome as it is, having a person and an algorithm read your mail is not comparable. Of course, the risk is that the results of the analysis is leaked outside the algorithm.
I have taken a conscious decision that I don't care about this risk. I'm putting my money (yes, it's a bet) on Google being able to profit better from advertising to me without violating my privacy. It's a "life's too short" trade-off.
http://www.zulius.com/how-to/set-up-postfix-with-a-remote-sm...
(1) file if the backend is mbox, folder if the backend is Maildir.
Doing a quick search this seems to be very close and up to date. http://www.owlfish.com/thoughts/dovecot-antispam-2011-03-21....
Getting it to work right was a little fiddly though.
Actually setting up a multi-user SMTP and IMAP server on Linux is straightforward if you've done it before, or it is here-be-dragons stuff if you haven't. (Your distro might configure it all up for you prepackaged, or you could be in for a lot of reading.) Integrating the bayesian filter is probably the easy part.
If it is only for you, it is perhaps easier to integrate it with your email app rather than at the server level. Popfile will do that.
I have traditionally used the instructions here which are very mature and have done me well for years:
They are absolutely bomb proof.
And you do get rather more than just postfix - there's webmail, IMAP, etc, all managed for you.
Because of the low volume of outgoing mail from a VPS, it's very easy to end up on blacklists.
When you are sending out a lot of email, recipients see a volume of mail. If a few of these get marked as spam, no big deal, you sent out 5,000 mails in an hour, of which 2-3 were marked as a false positive.
If you are running your own VPS you are sending out comparatively fewer mails so the decision on whether you are a spammer or not is made with a lot less information -- and most recipients will assume you are a spammer immediately.
I was on the wrong end of blacklisting situation and it was extremely frustrating. First, you don't know that your customers aren't receiving the emails. Second, you have very little clout in getting things cleared up. Third, it's just a huge PITA that wastes a lot of time.
I'm running a very small operation, but one bad instance of my IP being blacklisted prompted me to shell out the extra $3 /months to have Rackspace send my emails.
The blacklist issues others have pointed out are real. Some IPs are on blacklists and you will not be able to get them removed without an outrageous amount of leg work. Most of the premium email hosting places make sure they're not on those blacklists.
Personally, I use FastMail.fm. I've gotten the impression that if TSHTF, they'll fix it fast. The price is reasonable. They're not Google. When I get a website up that can't be served via static pages, I'll be going the VPS or other cloud service, but for email, I'm much happier leaving that to a premium provider.
Use a spam service such as spamhero.com or google postini as the MX for your domain so you do not have to do spam filtering yourself, have the spam filter service deliver the mail to your application (over SMTP). Your app can do whatever processing it needs to do, and then deliver the mail to the MX server of the ISP you're using to host your mail.
This way you can use your app without any changes as a local smtp filter as well (e.g. if you're using something like amavis).
* use a service like http://mailgun.net/
* install http://lamsonproject.org/ on your server and define a forward from your hosted solution to your server
* run your own mail server and use something like procmail to execute scripts or combine it with lamson/something similar
We recently switched over to Atmail (http://atmail.com/) after years of running Cyrus+Postfix (with various anti-spam tools). Atmail is kinda the best of two worlds -- you have control over your data, but the software is easy to maintain. Under the hood, Atmail is using standard Unix/Linux components (dovecot, exim, spamassasin etc), but makes it easy to maintain.
For a few other companies I'm involved with, I've deployed Google Apps, just because it's dead simple and gives you no headache.
1. I can choose my domain (although nowadays that's not a problem - it was when I first started).
2. I can tweak spam and anti-virus filtering.
3. I can view the logs if I think something is wrong.
4. I can be as (in)tolerant of other mail servers as I want (I've noticed that Google is a bit lax in the rules it enforces with regards to rejecting mail).
5. I don't trust Google or other providers not to mine my email, or to back it up.
6. It's a useful learning experience.
Huge disadvantage (other than the fact that power, static IP etc are all your problem) is that a LOT of email providers will think you are spam.
Now I use SES for outgoing (for my app) and Gmail for incoming. Works a lot better. I remember reading that Gmail lets you write filters and what not as well, but I have not examined it in detail. I'm sure its do-able.
Some things that are rather important:
1. Name your email server with "mail" some where in the name. Seriously don't call your email server crapbox.snaphop.com :)
2. Although you can send email as a relay on many different ports (2525, 8025, 587 (ssl)) you can really only receive on port 25.
3. You better have a PTR / reverse dns setup.
4. It takes at least a couple of hours before email servers will acknowledge you.
5. You can get away with out a SPF for a little bit but you really need if your going to blast a crap load of emails. Use this to test: http://www.kitterman.com/spf/validate.html
6. Some (most?) hosting providers are black listed and getting other email systems to recognize you as a valid agent is getting tougher and tougher.
7. You have to provide your own fail-over, or purchase it from someone else.
did this recently on EC2 and found these helpful
http://pauldowman.com/2008/02/17/smtp-mail-from-ec2-web-serv...
http://www.practicalclouds.com/content/guide/sending-email-e...
DKIM on Ubuntu - https://help.ubuntu.com/community/Postfix/DKIM
Microsoft SPF record creation wizard - http://www.microsoft.com/mscorp/safety/content/technologies/...
not sending that much mail, but noticed after setting up SPF/DKIM/reverse DNS that the mail I sent to myself didn't end up in spam folders at gmail and hotmail etc., without having to send via a service like authsmtp.com.
Instead, either use your ISPs mail server as a smarthost (if they allow it) or (better imho) get a small VPS of your own (e.g from Linode) and:
1). Install open dkim and set it to sign all your outgoing mail (make sure to add the relevant DKIM TXT records to your domains)
2). Add SPF records to all your domains
3). Make sure your server's IP has reverse dns setup
Your mail should then happily sail through all but the most brutal of spam filters.
Later on Hula struggled badly with Novell, was sold and forked, we tried to check out the forked version (Bongo I think) but so far the project seemed dead.
After a while we did a clean setup after failing a distribution upgrade (but hey 5 years updating without hitch on custom kernel and compiled software), we moved to debian to lessen maintenance, email was done via postfix+dovecoat+postgresql, which was a hassle (to say at least) to configure, funny enough this setup did not perform well, looking for a more consolidated solution we found Apache James, which looked fairly promising (being under the Apache foundation), the only downside was that it was written in Java, not that I have anything against it but that is another vm to install and maintain, we gave it a try and we have been very satisfied with the results, easy to administrate, very sane defaults, relatively easy configuration in case of tweaks (having it use our postgresql db for users was pretty easy compared to postfix/dovecot), it sucks a lot of memory but the machine overall feels even faster that with the postfix/dovecot stack.
So yeah, while its nice to have an email stack that follows the Unix philosophy, it can get very unwieldy for simple setups (while it may shine on complex setups where flexibility is needed).
It only took me a couple of hours to set up an encrypted VPS with Postfix and Dovecot, change the DNS and test that everything works ok. I'm somewhat lucky that I don't get too much spam and Thunderbird does a decent job of filtering it.
I do like step by step guides as they provide a higher level of control, but after you've performed a setup like that 2-3 times, you start to lean towards more automated installs as iredmail or custom written scripts. So why maintain your own scripts when you can start with a ready made package.
For sending email, there are some steps for DNS and signing missing here that can result in your email going to spam with the major ISPs. It looks like he was going to add Domain Keys in v6 but abandoned it.
This one was written by me, for Debian Squeeze...
IMHO, it's the best opensource groupware offering out there.
sudo apt-get install postfix
Then hit enter a few times to select the defaults.