
Taking e-mail back, part 4: The finale, with webmail and everything after - tambourine_man
http://arstechnica.com/information-technology/2014/04/taking-e-mail-back-part-4-the-finale-with-webmail-everything-after/
======
bitJericho
In order to setup an email server you really should have at least 2 MX servers
accepting mail in case one is down. It really _really_ sucks when emails are
delayed and the sender gets that delayed message.

The simplest self-hosting solution I've found is to setup 2 cheap VPS servers
that accept mail via postfix (128mb, maybe 256mb if you want to virus scan at
this point, a good idea), and they both can deliver email to an in-house
server running roundcube or zarafa or whatever, when the internal server is up
and running. As long as the VPSes are up, they hold email until the server
inside your local network is up and running.

This means you bypass the very messy "secondary mx" issues, as you only have
one internal server to worry about that accepts email arbitrarily from the 2
public server, and you can backup your internal server just like a normal PC.

~~~
computer
An alternative is to use some email server from a host/domain registrar/google
apps/zoho/etc as secondary MX server. It saves you from having to maintain a
second server, and you still get 99% of your messages through your primary
server.

I had a similar setup for a while, and it was interesting to see that some
messages (spam, mostly) picked the secondary MX by default. Spam servers also
seemed to cache the (secondary) MX for much longer than the TTL.

~~~
rakoo
Spammers believe that secondary MXs are set up "in case of emergency", so they
must have less restrictions on what goes in (so you don't miss an email) and
must be less maintained... meaning that spam goes in more easily.

------
Theodores
For anyone wanting to setup a mail server this is the best guide going. I read
Part 1 and had to find my own way.

Incidentally, if you are trying to read email or send email with code, having
your own email server, working with a desktop client is a very useful starting
point. You can downgrade the spam filtering, the SPF record checking, the
SSL/TLS sign on until you have something that can read IMAP or POP. This is
where the real fun begins as emails come in various multi-part formats, there
are lots of character sets to translate to UTF-8 and there is base64 to deal
with. If you can reliably read the header of an email and extract something
simple like the date then you are doing very well.

------
laacz
This guide is really good as it goes almost whole mile.

It also does very good if not excellent job at illustrating how hard it is to
set up, secure, and maintain your own email service. There are lot of places
to go from here, including multiple MX'es, backup/recovery, etc.

Nevertheless. I've been using my own email infrastructure for almost ten years
years. For last four I'm totally over it. Yes, there are some things to do if
you absolutely want to be free to chose your email provider whenever you want
to - having clear choice where to go, having backup off service provider,
having migration strategy in place, etc.

------
donniezazen
I feel like any data that is being transferred over internet has a real
possibility of being surveilled on. Amazon AWS or any other storage provider
has to comply with any three letter agency. Calling this secure sound like
calling random numbers as random. What do you guys think?

------
binaryapparatus
Email is fundamentally flawed, or better put it is not up to challenges of
time. While I am reading this ars articles with great interest and was toying
with the idea of rolling my own email server, series size and complexity serve
as a best argument of email flawed state. We are fixing and patching and
protecting something that fundamentally can't be that well fixed, patched and
protected. We need to reinvent everything.

~~~
lukifer
Nothing is perfect, least of all email. But it did one thing right, and it's a
big one: any email user can send to any other email user, regardless of
provider or platform. We still lack that capability when it comes to IM,
social networks, and most software in general.

~~~
rakoo
> We still lack that capability when it comes to IM

No, we do have this capability: use XMPP.

In fact, XMPP is functionally enough to completely replace email, and does
also serve as IM.

~~~
MetaCosm
Theory versus reality. The theory of federated XMPP is exactly as you said.

The reality is much more of a mess, with multi-device issues -- routing issues
-- federation issues, not to mention a ton of non-XMPP messaging services.

~~~
frabcus
And most importantly, no identity system _which end users know about_. (i.e.
people know about email addresses, but Facebook users use XMPP without knowing
how to refer to people on other services)

