[_asciiker_]

The reason for SMTP servers being better off in a proper data-center is not really due to port 25 being blocked at home, it's the entire infrastructure that assures reliability, so if your power goes out or your home router decides to die or your ISP is having issues, etc, you would start losing emails right away.

EDIT: I understand SMTPs are resilient but it also depends on the type of error they get back, even then it can't be expected that all servers keep retrying for long periods of time or even handle triple bounces. So you 'could' start losing emails right away, is a better way of saying it.

[jakobegger]

Isn't SMTP actually pretty resilient to outages? Typically sending mail servers will retry for hours (or even days) before giving up when a recipient server is down.

[bhauer]

Yes, it is. Virtually all normal SMTP servers will re-try e-mail delivery several times spaced over at least several hours before rejecting delivery with a notification back to the sender.

I have run my own e-mail server for about 17 years, originally from my home and more recently from a data-center where I have co-located my server. Admittedly, when I had my mail server at my home, I would suffer outages long enough to miss e-mails when I needed to do something as severe as work on my home's electrical panel or move. But generally speaking, a momentary glitch in network connectivity would not result in lost e-mail. Since moving my server to a data-center, the only downtime I had was when I needed to replace a disk.

As the above paragraph suggests, I am strongly in favor of people running their own mail servers and moving away from the presently-popular centralized Internet, back toward a decentralized model. This device isn't for me, and probably isn't for several of us here, but it's precisely the kind of thing I'd like to suggest to other people who would not otherwise be comfortable running a mail server.

I know a lot of programmers who shiver at the thought of managing their own servers, and I feel that's a regretful situation for the Internet at large. It suggests two things: (a) many programmers fear servers, which I don't think is healthy and (b) insufficient R&D has gone into making infrastructure easier to manage. After all (a) is a rational fear given the state of the art in many cases. It can in fact be quite difficult to set up a mail server (although once setup, most are pretty hands-off). It should be much easier to navigate through the settings and have a nearly out-of-the-box configuration that is sane and avoids the most common pitfalls.

Aside: Incidentally, I found that even mainstream ISPs like AT&T will unblock port 25 if you call them up and explain you are running your own personal mail server. When I moved to AT&T country, they did exactly that with no questions asked.

[mbrock]

Great comment.

As for programmers fearing servers: all the mail servers I've tried are almost incredibly byzantine, making them stressful to configure and hard to understand.

My brother got tired of this and wrote a functioning and mostly conformant SMTP server in less than 50 lines of bash (using djb's tcpserver and delivering to maildrop).

As far as I'm concerned, all the configuration I can ever imagine needing for a simple SMTP server could be specified with like max 3 command line switches.

So yeah, I think it is a somewhat rational fear, and I don't understand why everything seems so amazingly complex.

[jlgaddis]

FWIW, OpenSMTPD is extremely simple to configure and get up and running. (I don't use it other than as an "outbound-only sender" but the configuration file is very readable and simple).

[c22]

To add to that I've found OpenBSD in general to be extremely easy to administer. Most configuration is straight forward and no more complex than necessary with very clear documentation.

[mbrock]

Cool, thanks.

[pavel_lishin]

> many programmers fear servers, which I don't think is healthy

I fear the consequences of doing it badly or wrongly. It's like building my own car - I could probably do it and drive it around for awhile, and if nothing goes wrong nothing would go wrong - but if something does, suddenly it goes very badly indeed.

[fche]

"Since moving my server to a data-center, the only downtime I had was when I needed to replace a disk."

By the way, there exist backup MX services - commercial or self-made, which would give you 100% incoming-mail uptime but without having to move or copy your server to a data center.

[jlgaddis]

Some hosts are doing away with backup MX hosts (including me/work) simply because a) any sane sender will retry for a period of at least several hours and b) sending via the backup MX is a common way for spammers to (attempt to) increase the chances of their mails getting delivered (e.g., due to lack of/decreased filtering on backup MX hosts).

[bhauer]

Thanks for the note! I'll definitely keep that in mind next time I evaluate my hosting environment. I expect to switch to a different data center eventually, and that would come in handy.

[vidarh]

Usually they will retry for days. 4 days is conventional, and it's rare to see less than 24 hours... So you're right, it's a rare concern.

And of course if that's an issue, it doesn't take a huge amount of effort to run two - the secondary only needs to run the MTA with sufficiently longer retry intervals for passing mail on to the primary to give you whatever safety margin you'd like.

People seem to forget that e-mail started out in an environment where not all recipient hosts could even be expected to be online all the time - there's decades worth of solutions for doing store and forwards for hosts with intermittent connectivity, so dealing with failure of an MTA is easy.

My big issue with running my own mail server these days, though, isn't the inbound e-mail but deliverability of outbound e-mail. These days I'd be inclined to pass my outbound messages through somewhere like Sendgrid or Mandrill (at a cost) to let someone else deal with the deliverability problem.

[spin]

I know a lot of programmers who shiver at the thought of managing their own servers...

I used to be a sysadmin; now I'm a programmer. I love to host my own webservers and the like. But email? That's just a never-ending uphill battle. Between spam, and whitelists, and botnets constantly port-scanning your server (hope I've got all the latest patches, etc..).

For me, GMail solved this. GMail solved spam, and hassle. (At the cost of all my privacy being in the hands of a for-profit corporation.)

[benedikt]

How do you authenticate your mail clients with your SMTP server? Do you use the same SMTP server for incoming and outgoing mail?

[bhauer]

Yes, same server for inbound and outbound.

[benedikt]

Do you have a smartphone connected to this setup? Do uyou use a password over SSL to authenticate your email clients?

[bhauer]

Yes, and yes, I use SSL and a password to authenticate the clients. I'm curious where this is going. :)

[McElroy]

Yes. This is correct. Once, I had misconfigured my mail server when adding another domain I had bought and it rejected an e-mail. While I was looking into it, I saw in the logs that the sending party had retried after 15 minutes so I corrected my config and waited another 15 and I got the e-mail. Of course, number of retries, if any, and time between attempts will vary between different servers and their configs.

Another story I have about e-mail is that another misconfiguration on my part caused mail from me to others to be spam filtered or outright dropped by some receivers. It wasn't until I attempted to send an e-mail to a Debian mailing list that I learned why that was. Their e-mail server was nice enough to reply with the exact reason why they would not accept my mail. I was then able to fix it. (Though I don't remember if they did so in the form of what was said over SMTP and seen by me in logs, or if they bounced the e-mail.)

[_asciiker_]

Depends on the error the DNS handler 'name.nospy.so' would throw at it.

[ryan-c]

This is somewhat mitigated by the fact that legitimate sending mail servers will retry delivery if the destination server is unavailable. Outbound mail from a home connection may very well have issues being marked as spam due to ip blacklists though.

[pjc50]

.. although the main reason for hosting email at home is that nowhere else is immune to search-and-seizure provisions.

[_asciiker_]

I don't think so, depends on where you live and the laws that apply there. It's probably easier to seize a home server than it is to hassle a company to divulge its contents.

[pjc50]

I think it's the other way round in the US. Conventional email hosting providers are definitely not protected by the 4th. Also for political activists, actually raiding their homes is a dead giveaway whereas leaning on companies can be done quietly.

[secfirstmd]

Or use a Covert Method of Entry approach...

[tiatia]

Should be easier to just encrypt all the email. Either by encrypting the HDD or by automatically encrypting all ingoing email with you public GPG key (Saw a perl script for this in a blog)

[jlgaddis]

RFCs dictate that a mail server retry sending when the MX host is unavailable. If the sending mail server doesn't retry then it is the sender's fault if a message is returned undeliverable without retrying at least a few times.

The "de facto standard" for retrying was (is?) five days, because that's what sendmail defaulted to for years. Nowadays, many senders don't retry that long (my mail systems are set for 48 hours) simply so that a bounce/undeliverable mail is returned to the sender much sooner.

IIRC, there was a certain version of Exchange (I forget which now) that apparently didn't retry and would immediately bounce a message if it was undeliverable on the first attempt, but that was quickly fixed.

[_asciiker_]

Wasn't the "de facto standard" set by QMail back in 1998 ?

[jlgaddis]

Perhaps, it very well could have been. I made an assumption since sendmail was, for the most part, the MTA in those days. Yes, others (including qmail) existed but sendmail was, by far, the most widely used. I, myself, was a sendmail fanboy for years until I eventually moved to postfix in the early/mid-2000s.

[lsc]

eh, it's a security vs. reliability issue. You are right that a home-hosted email is going to be less reliable. Others are right that SMTP is pretty resilient, but not infinitely so.

A home mail server, from experience and from the experiences of others, would work okay on receive. You want a static IP (or a static-IP VPN.) at a minimum, and the first thing you need is to make sure you aren't on the dialup-user lists. But that's an outgoing mail issue, not an incoming mail issue.

that's the thing, though, the outgoing mail issue, ultimately, is more difficult than the incoming mail issue.

[slg]

It isn't only receiving emails that requires a connection. According to the site, anyone who doesn't use encryption (currently the vast majority of users) will receive a link to your message hosted on the device. That means that most people won't be able to read your emails if your device goes offline.

[rythie]

It doesn't seem a big leap to have a small UPS at home ($42 gets you 37mins@20W) or even a rechargable battery in the router and mail server.

Further resilence could be handled by partering with another device at a trusted person's house, to act as a backup MX server.

[shubhamjain]

Neither does, making Dropbox itself, "trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software." [1] :)

[1]: https://news.ycombinator.com/item?id=8863

[rythie]

Obviously it needs to be a lot easier than that - the fact that it's difficult right now is the problem. It needs to easy to manage like a smart phone or tablet is.

[nadams]

Most reliable SMTP servers will retry for some amount of time.

[timboslice]

Yes, I can only see this being used with an SMTP relay, which seems to kind of defeat the purpose of self hosting