Similar to Let's Encrypt, the project providing free SSL certificates for web servers along with tools to auto-renew them, STARTTLS Everywhere is trying to build some tools to make it easier to configure your mail server to encrypt mail in transit, and do so with properly signed certificates.What I only just realized is that it's pretty easy to use Let's Encrypt certs as SMTP TLS certs, if you have already been using self-signed certs: you just need to add your MX to the list of domains in the cert and install that cert into Postfix:
smtpd_tls_cert_file = /etc/
smtpd_tls_key_file = /etc/
smtp_tls_cert_file = $smtpd_tls_cert_file
smtp_tls_key_file = $smtpd_tls_key_file
They have a page that tests your server, but it's terrible, don't bother. If it detects a single problem it just says "Nope!" without telling you what the problem is. A better tester is at checktls.com which will actually tell you what it thinks went wrong.
Wow, Everything's So Messed Up. How Is STARTTLS Everywhere Going to Help?
We have three primary goals for STARTTLS Everywhere:
Improve STARTTLS adoption.
We want to make it easy to deploy STARTTLS with valid certificates on mailservers. We're developing Certbot plugins for popular MTA software, starting with Postfix, to make this a reality. [...]Prevent STARTTLS downgrade attacks.
In order to detect downgrade attacks, we're hosting a policy list of mailservers that we know support STARTTLS. This list acts essentially as a preload list of MTA-STS security policies. [...]Lower the barriers to entry for running a secure mailserver.
Email was designed as a federated and decentralized communication protocol. Since then, the ecosystem has centralized dramatically, and it has become exponentially more difficult to run your own mailserver. The complexity of running an email service is compounded by the anti-spam arms race that small mail operators are thrust into. At the very least, we'd like to lower the barriers to entry for running a functional, secure mailserver.
Yeah, see, that last part is the kicker. Only crazy people like me run their own mail server, because Google has managed to almost completely de-federate the world's email infrastructure. "Google has most of my email because it has all of yours".
Why would anyone run their own mail server?
"As an act of defiance against the Google hegemony" is probably not a selling point that resonates with very many people.
Nor is, "I really enjoy reading my logs and seeing Error 421: To protect our users from spam, mail sent from your IP address has been temporarily rate limited."
So, you know, maybe some day everyone who still runs their own email server will have certificates installed, and maybe enough of those certificates will be signed by a CA that validating the cert before exchanging mail might be a practical thing to do. But it's more likely that by then, email will have been killed as a concept. All it would take would be for Google to decide, "Fuck it, we're just not going to federate with anyone any more."
You know, like they did with GChat, single-handedly killing Jabber / XMPP.
They don't quite have the market share on the email side to get away with that right now, but maybe they will someday. But even today, they could probably get away with saying "We're no longer accepting SMTP connections, period": they'd just have to bully Outlook, Yahoo and iCloud into peering in some new way that locks everyone else out. They'd do this under the guise of "solving spam", which it wouldn't.
In summary, everything is terrible.
Previously, previously, previously, previously, previously, previously.
I run my own at work, and let me tell you, it's not easy. I do it because I want full control of my company's email and it's worth it.
The marketing manager quit awhile ago and didn't hand over monitoring of our Google inbox rank to the new guy, so when suddenly all our mail to Google (90%?) was being spamboxed, we were just screwed. I mean, we're paying for rehab from Sendgrid, but our inbox rate is still crap. And there's no human to talk to, it's all algorithms all the way down.
Server's perfectly configured, passes every SPF/DMARK test, fully SSL... but Google decides if your email arrives or not no matter what.
SPF/DMARK don't (shouldn't) make your email not spam, it just means your email was definitely from you, which if email from you is spam, means this was definitely spam.
In practice the ordinary person's understanding of "spam" is not unsolicited advertising but "I didn't want this". They may feel they "didn't want this" even if they are literally paying for it as an actual subscription service. It's their INBOX's dislike button. And so of course many people dislike scams and junk using harvested email addresses, but they also dislike an email telling them their preferred political candidate lied directly to Congress, a bank notice that they're overdrawn, and every email they'd really rather not look at, which for a lot of users is basically all of them.
The end result is that if you send email to users, some, and perhaps even most of them will mark it "spam" unless they really, really wanted to receive that email, and that's going to impact any "reputation" type metrics tracked. "Email deliverability" companies specialise in fudging that reputation to try to get your email into the "not spam" pile.
We cannot have nice things because we are idiots. That's hopefully not news.
As someone volunteering as the IT head for a small non-profit doing its own web/email/etc. on a VPS (for now): Yes, all of this. Compounded in my case by the fact that the non-profit is trying to defray the cost of the VPS by selling server space to other non-profits, some of which have gotten hacked and sent out spam for a good few hours at points, because it's all volunteers and the person who set this up didn't think about what it means to be a hosting provider...
...and we'll leave aside that this non-profit is using mailman email lists for everything, which means suddenly wide swaths of folks get cut off...
...and G Suite for non-profits is looking nicer by the day, as is "We can't do email lists anymore, it's too much of a PITA."
/run-on-rant
Possibly dropping both... everyone gets a G Suite email instead of a forwarder and it's webforum time.
Yeah, I know how email works. The marketing asshole who fucked off and didn't leave anyone at the rudder screwed us good.
SPF, etc are useful not because they make your email obviously not spam, but because they make other people's forged crap not your problem. With authentication, your domain can have a reputation, and spammers can't besmirch it. Otherwise you're stuck with whatever reputation your IP address has.
If, as you say, your own reputation is crap because you are boring or deliver bad news and no one wants to hear from you... Yeah, that's a different problem.
I used to use Gmail and the google apps version of gmail to run everything, but I decided that I didn't want to give them that much control to mess me up by blocking my account. I switched to Zoho hosting instead. I really think that everyone should try and move their email off google, but I doubt that will ever happen.
Because of Spam from other servers, and convincing other servers that you're not sending spam, it's a nightmare to run your own email server. Luckily there's services still that aren't Google.
I’ve been using the LetsEncrypt certs for both web & mail traffic since StartSSL had their ... issues, and I never realised there was a /need/ for STARTTLS Everywhere. That checktls link was handy, though - one of the servers I run is missing its cert chain AND is configured with a backup MX which doesn’t support TLS (how’s that for a downgrade attack?)
I don't know what you're complaining about. Just convince everyone you email to set up their own mail server, on a FSPL compliant system.
This is so fake, but what's real anymore?
And why postfix instead of exim4?
Routers are if statements:
https://en.wikipedia.org/wiki/Philip_Hazel
What is the purpose of
smtp_tls_cert_file = $smtpd_tls_cert_file
smtp_tls_key_file = $smtpd_tls_key_file
? Postfix's documentation says these are for specifying a _client_ certificate, and recommends keeping them unset. AFAIU certificates issued by LetsEncrypt cannot be used as client certificates in any case?
"Cannot" is a strong word. It would be possible to set an Extended Key Usage which said the certs were only intended to identify a TLS (SSL) server, and it would be possible to write a server which examined certificates and, if they lacked an EKU saying they're suitable for identifying a TLS client rejects the cert.
But, actually certs issued by Let's Encrypt have an EKU saying they're for identifying both TLS clients AND TLS servers, and also nobody bothers checking EKUs in most software. Indeed a lot of web browsers only recently (last few years) got around to checking for the TLS server EKU in a cert sent by a server, until they did that if you were able to convince a trusted CA that your "real" name was Google.com they might issue you a certificate saying CN=Google.com, and a web browser might conclude that's fine as a server certificate... the CA would say "Oh, we didn't intend that for web servers" and the browser says "Well we didn't realise" and it's nobody's fault... Today I am confident this trick wouldn't work on (current) Firefox or Chrome, and semi-confident it doesn't work in Safari, but IE and Edge are anybody's guess.
It's not just EKUs, nobody checks basic key usage fields either. In theory you should be able to issue a certificate that says this public key is not for signature checks, only use it to do old-school RSA key agreement, if a server tries to get you to use it for signature verification, that's bogus, refuse. For example if it worked today this could indirectly make TLS 1.3 more secure. But in practice checking for that causes things to break, we're probably years away from being able to insist on it and by then it won't matter for TLS 1.3 so there's an attitude of "Well, I'm not dying on that hill" and it never gets fixed.
Anyway, in a mail relay server it might be reasonable to offer your cert as a client cert. This lets you say "I am mail-relay.jwz.org, here's proof" when connecting to somebody else, as well as when they connect to you.
Another crazy person here. I've used a self-signed cert in STARTTLS for years, but did consider switching to the Let's Encrypt cert when I set that up. Still might.
Occasionally I check logs to see what proportion of my mail traffic is encrypted. It's surprisingly high.
Oh also, I tried that checktls tester and it mostly passed me, except it choked on my graylisting! Hah hah!
S/MIME everywhere when?
It'd be wonderful if there were more than one place in the entire world you could get a personal S/MIME certificate and if I weren't the only person in the entire world who used it. Rid the world of the oppressive scourge of PGP.
End to end encryption seems like a more important goal than inter-relay encryption, and we've already trained everyone to basically understand how the UI works for hierarchical PKI. That train really needs to get rolling before some yahoo decides that the world really needs a proprietary email protocol because the current one "lacks" security feaures.
So of course after going down this minor rathole I discover that somehow my outgoing mail no longer had any DKIM headers. Why? Probably because something got "upgraded". And because opendkim has no diagnostics of any kind. How long ago did it happen? I have no idea. Did it have any appreciable affect on anything? I have no idea.
Running your own mail server is greaaaaaaat....
Nonsense like this was why I eventually punted and moved even my personal domains over to gmail back when that was a free thing. I get the emotional/philosophical appeal of running your own SMTP server but more than anything else the anti-spam rathole just went down forever and when I realized that I was seriously considering upgrading my dumb personal colo box (which serves shell and web pages for, like, 7 aging nerds) to a multi-core system just for spamassassin and clamav to have dedicated CPUs was when I realized I was seriously misvaluing both my time and my discretionary income. I wish there were a better way. :(
Also as someone who was occasionally paid to deploy and manage Jabber/XMPP servers? That project was a dead man walking for its entire lifecycle. Say what you will about the vagaries of running your own email server, "just run postfix" will get you a fully functional email router that implements the entire fucking protocol, and there were multiple competing projects that you could say the same thing of. Jabber never once managed to hit a point of ecosystem stability where you could point to an obvious best-of-breed implementation (server or client) that you could safely assume would run the union set of all features your users cared about including basic stuff like multi-user chats. Instead it was an endless hell of "server X supports XEP FROBOZZ but only clients A, C and Z implement that and the only OSX desktop client that's not a fucking recompiled KDE app requires XEP FROBNIT and oh BTW none of this crap works at all on mobile which is all anyone cares about...
Sorry, I may be a little bitter.
It always struck me that XMPP was conceived of as "a chat system using XML" first and foremost, rather than "a reasonable real-time messaging protocol". The whole thing seemed doomed from the start, and while it got a whole lot more traction than I initially guessed, it doesn't seem to have achieved any of its stated goals, other than, indeed, being, mostly "a chat system using XML".
Here's from one bitter person to another.
Many things sucked about it, but there was a period of a few years when I was able to use a single chat client, Adium, to talk to people using disparate services (Google, Livejournal, Facebook, as well as various Jabber servers) because they all federated via XMPP. All that's gone now and the reason was a desire for lock-in, not some technical debate over the merits of the protocol.
Absolutely fair point. Too easily lost in the details, I.
I tried https://starttls-everywhere.org/ last night. It failed my mail server since I only allow TLS >= 1.2. It wants TLS 1.0 ( "Warning: Server should support TLSv1.0, but doesn't." ), which is deprecated at the end of the month for PCI compliance: https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls
This is maybe the wrong place to ask this, but do people have thoughts about Migadu? I am trying it out right now but would appreciate anything Actually Professional Mail People have to say.
I get that people shy away from the hassle of running their own mail server. I still do it (and have happily been using STARTTLS for a while), but have outsourced spam filtering. It is great to have the benefits -- e.g. a new alias for another website in an instant --, but I get a little weary of the work sometimes.
But Google isn't the only one. There is Fastmail, for instance. Not for free, but with very reasonable offerings, and technically they are excellent.
Only drawback: they have their infrastructure abroad (from my point of view), and I don't want to have my mail in the reach of more authorities than strictly necessary -- particularly not in a Five Eyes country. If they had their servers in my own country (.de), I'd transfer everything to them to get rid of that work.
There are other, very decent email providers where I live, just not as good as Fastmail, so I'll stick with my own private mail server for a while.