Hacker News new | ask | show | jobs
by emergentcypher 3777 days ago
Now I can just get a free cert and turn on TLS. What's the problem, exactly?

Most people are not capable of running their own mail server. The convenience of services like Google, plus the risk of turning your mail box into a spam machine, vastly outweighs the downsides for most people.

3 comments

> What's the problem, exactly?

> Most people are not capable of running their own mail server.

I think that is a big part of the problem. It should be relatively straightforward for someone who isn't a full-time email server administrator to setup a mail server correctly, but it's not. At least, it wasn't easy last time I tried it with Postfix and (iirc) Courier on Ubuntu. All the cryptography options are disabled by default and you have to spend a lot of time figuring out which ones should be turned on, where to stick the certificate files and how they should be formatted, how to get Courier and Postfix to talk to each other, etc...

Maybe there's an easy solution (besides "pay someone a monthly fee to manage this all for me") that I'm oblivious to, but it seemed like I was on a well-travelled path and it was a lot harder than it should have been.

If it helps, I recently rebuilt my mail server and changed from FreeBSD+qmail+Courier to Ubuntu+Postfix+Dovecot. In doing so, I used this series from Ars Technica:

http://arstechnica.com/information-technology/2014/02/how-to...

It shows how to set up SPF, DKIM, TLS, anti-spam filtering, Sieve, certificate-based authentication (I still haven't figured out how to do this with an iPhone), and so on. The only bolt-on it references but doesn't explore and I actually used is the Z-Push package to implement ActiveSync.

Thanks for the interesting link, I've been curious for a while about running my own email server.

Do you encrypt the email on disk, or are they stored in plain text?

are you able to mail folks at google/live without going to spam? Genuinely curious.
Yes. I periodically test with various recipients and mail goes through without a hitch. The only difference I might have versus people starting out fresh is that the domains I host are relatively aged. The newest is two years old and the oldest is nineteen. I also made sure that DNS is set up properly, both forward and reverse, and especially for IPv6.
maybe my sin is hosting at linode - for a new recipient at either of the behemoths, I seem to have 50% chance of going to spam. Thanks for your comment.
I host with linode, and have had generally good results sending mail to gmail. They're definitely not the worst. Granted, I have had SPF enabled for about 10 years.
Most ISPs don't allow inbound (or, often, outbound) connections on port 25, so the number of people who can run mail servers at home is pretty limited. I think even Cox stopped allowing it a while ago, and they were among the most lenient of the big ISPs. (Comcast hasn't allowed it for a while.)

That, I think, is why the distribution managers don't make the default configurations a little more friendly/sane; most users aren't interested in installing a MTA to do anything but local delivery or smarthosting, and the people who are, are probably going to tweak the configs to death anyway, so it's not worth spending the time making it run well and securely straight out of the box.

It wouldn't be too hard to build a "mailserver in a box" with (say) Debian + Postfix + LetsEncrypt + BIND that you could stand up in an hour and be reasonably secure (and I'd be kinda surprised if that doesn't exist in some form already), but I don't know how many people would want it who aren't running mailservers already, and have the capability of doing so.

So run it on AWS. In general, I think running mail servers off a residential, or even business ISP is very sketchy. E-mail is my primary line of communication for important matters, and I can't afford to have a snowstorm, busted hard drive, orange juice spill, or basement flood take out my mail sever.
I don't think it's "sketchy" to have different requirements. For my personal needs, email is definitively important, but it doesn't need HA, and its store-and-forward architecture means it copes fine with an hour or six of downtime (serves usually retry for several days until giving up).
Ec2 blocks/throttles outgoing smtp
EC2 blocks/throttles outgoing SMTP by default.

As with so many things in AWS, it's left up to the customer to inform AWS that a) you're running a mail server, b) what the purpose/use case is and c) request they configure the reverse lookup associated with the elastic IP you've allocated.

Source: I've been running public facing SMTP servers in EC2 for years with no issues.

AWS also has an outbound SMTP service you can use:

https://aws.amazon.com/ses/faqs/

Still, unless you're running a server for a lot of people and you have tons of free time, you'll discover that it's more expensive than paying any of a bunch of people to take care of email for you.

Source: I work at FastMail

If you make hard things easy to do, then people that don't know what they are doing will do it (poorly). They'll set up a server once, and never maintain or update it and it'll eventually be hacked and taken over by spammers. I set up and maintain our mail servers and work, and for my personal email, I chose to point my domain to Gmail to let Google take care of it, I don't want to expend the effort it takes to run my own mail server.
Have a look at opensmtpd. Easiest-to-configure mail server I've ever used.

https://www.opensmtpd.org/

I tried it on Ubuntu 14.04, but unfortunately you get only pretty old versions, even via PPA. And no matter what I did, opensmtpd crashed each time it received a mail from localhost to a local receiver.

I'm having high hopes for Ubuntu 16.04 having a more recent version on board. Then I will try to switch from postfix again. Because as you've said, it's really straightforward to set up :)

>Now I can just get a free cert and turn on TLS. What's the problem, exactly?

Certs weren't free for business use until let's encrypt.

Long before Let's Encrypt, SMTP transactions with STARTTLS have permitted self-signed and non-root-CA chained certificates.

The pervasiveness of self-signed certificates for SMTP servers means that rejecting them would drop large amounts of email. STARTTLS is basically useful for thwarting passive collection of network traffic.

Gmail's new rules on unencrypted e-mail don't support self-signed certificates though - you have to use an offcial CA-issued certificate from one of Google's approved CAs.
I'm not so sure about that; I use a self-signed cert for port 25 TLS, and I just sent from google to my domain, and didn't see a warning.
What's your source for that?
That doesn't bring a lot of extra security though, because there's no name verification. I can get a valid letsencrypt cert on anyrandomdomain.com, and if I can hijack your MX and point at it, it's "valid".
What? How can you get a cert for a domain you don't control?
I don't need to control your domain. If I control my own domain, which could be any throwaway domain I just purchased, I can get an SSL certificate on it.

And if I can point your MX records there, via hijack or any other means, then I have a valid SSL certificate for receiving your email.

That's kind of the point. They weren't but now are, and now there's even less of an excuse not to have a cert.
Is it possible to get a Let's Encrypt certificate without a public facing website (which is unrelated to wanted to run a mail server)?
Yes, they recently enabled the DNS validation. Otherwise, it wants to use a webserver to validate ownership. It can spin up an embedded webserver if you don't have one already.
I would say the opposite: There is no excuse for cementing the role of CAs for SMTP. DANE doesn't need any CA, and there is no problem with legacy clients that require CA-signed certs.
It's been a long time since the cost of a cert was an inhibiting factor - at least for 1st world businesses. (I don't suppose I'd want to be paying for a US dollar priced TLS cert in Zambian kwacha or trying to get a petty cash reimbursement for one on a typical IT salary in South Sudan...)
WoSign never seemed to care.
My first concern is, if nowadays is so easy to get your certs signed by a CA how can "Authenticated/Encrypted" emails successfully prevent phishing attacks? In my modest opinion there are many week points in X.509 and how CAs are verifying identities, and even if this things were fixed you still have the problem of state-sponsored attacks that have no solution within the current www pki. I personally have no problem if Google wants to add some icon in the UI, but I share OP's concerns.
The use of TLS (which is what uses a CA-issued certificate) isn't to prevent phishing attacks, it's to prevent emails being read or modified in transit.

DKIM (which does not use a CA-issued certificate, it uses a public key published in DNS) is the technology that's intended to authenticate the email sender. It still wouldn't stop phishing attacks where the purported email sender is something like "admin@facebook-account-verification-2016.net" though, and I don't know that there really is a good technical solution to that sort of thing.

> to prevent emails being read or modified in transit

Except everything you send and receive with your Gmail account is read by them and whatever government agencies anyway... So what's the point?