Selfhosted Email by Maddy on Oracle Cloud | Hacker News Reader

Selfhosted Email by Maddy on Oracle Cloud

taoshu.in

27 pointsunclet47 comments

> And the finally ~all means if the sender connect fullfill the rule of SPF, the email delivered should be move to trash.

No it doesn’t. “-all” would mean that. What “~all” means is that it merely suggests that the mail might be invalid.

Or, to quote RFC 7208:

A "softfail" result ought to be treated as somewhere between "fail" and "neutral"/"none". The ADMD believes the host is not authorized but is not willing to make a strong policy statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.

The ADMD wants to discourage the use of this host and thus desires limited feedback when a "softfail" result occurs. For example, the recipient's MUA could highlight the "softfail" status, or the receiving MTA could give the sender a message using greylisting [RFC6647], with a note the first time the message is received, but accept it on a later attempt based on receiver policy.

> apt-get install gcc libc6-dev make

Note: There’s an easier, more canonical way to do that:

  apt install build-essential

> If you need a web interface, you may be intrested in Roundcube or Squirrelmail.

I thought RainLoop was the new hot thing. (<https://www.rainloop.net/>)

I understand Squirrelmail to be basically dead for over a decade.

It was removed from Debian in 2016. But there seems to be some recent activity: <https://squirrelmail.org/>, <https://sourceforge.net/projects/squirrelmail/>

Mentions, but does not cover, DANE and TLSA. It does cover the stupider alternative, MTA-STS, which is basically DANE for people who are politically against DNSSEC.

I don't know, I find that most people are against DNSSEC for non-political reasons. Did Chrome drop support for political reasons? No.

Covering MTA-STS is practical. The fact they do so wins them points towards having built something that works in the real world.

Chrome has no business “supporting” DNSSEC in the first place; it should all be handled by the operating system and the resolver. So I don’t think this is a point against DNSSEC.

My guess is that people are against DNSSEC because it’s difficult. You know how people are saying “It’s always DNS”? People hate dealing with DNS, because they don’t understand it. And DNSSEC is then another dimension of difficulty on top of that. But DANE is clearly the technically better solution. I mean, MTA-STS requires a file to be served from an HTTP server to even work. So now you need an HTTP server in addition to your SMTP server!

In any case, you should not, probably, deal with DNSSEC yourself! Note how the article does not cover running your own DNS server, but instead vaguely talks about editing DNS records. And if you have your DNS hosted by somebody else, DNSSEC is their problem. And once you have DNSSEC provided for you, you can use DANE and TLSA records without issue, without having to host an HTTP server for MTA-STS.

To protect my email with DANE, I ended up running DNS myself. I used to be at AWS Route53. It supports DNSSEC (but quite user-unfriendly). But it does not support TLSA records (!). I'm still curious why, though Route53 is giving off a vibe of being frozen in time (a long time ago).

Anyway, modern bind or knot take care of the keying part pretty much automatically (this made DNSSEC harder in the past). Just add records to the zone file, reload zone. DNSSEC signing is automatic and changes propagated to secondaries.

I agree with you that DANE is a better solution. MTA-STS adding a webserver and HTTP libraries to email as requirement is a bit much. Also, where DANE is per MX host, MTA-STS is per recipient domain, requiring a TLS certificate for each (operationally not great when you're hosting many domains). MTA-STS also relies on mail servers keeping track of historically retrieved policies, which must be refreshed in the background. And if a first connection attempt is intercepted (falsely getting told no _mta-sts DNS record exists), there is no protection. This isn't possible with DANE.

Route53 infamously used to have a bug in their DNSSEC signing of wildcard records, which was the thing which made Slack try to back out of their DNSSEC rollout. (And then Slack badly botched the backing out, essentially locking themselves out of the internet for an entire day. Discussed here: <https://news.ycombinator.com/item?id=29378633>)

I would like to add the DANE and TLSA part. However, I do not understand how it works currently.

If someone wants to send e-mail to user@example.net, they first look up the MX records of example.net. Say, for example, that the MX record for example.net contains the mail server “mailserver.example.com”. (Note the different domain name.) The e-mail sender then looks up the TLSA records of the DNS name “_25._tcp.mailserver.example.com”. The TLSA records contain hashes of keys. The communication to the mail server must support TLS, and must use one of the keys which are listed by the TLSA records, otherwise the communication is regarded as insecure or under attack, and is considered to have failed, similar to if a server cannot be reached.

Also, for DANE to work, both the MX lookup and the TLSA lookups must support DNSSEC! Note well that this means that, in this example, both the domains “example.net” and “example.com” must be signed by DNSSEC for DANE to work.

One wrinkle is that if you use ACME to renew your certificates, you have to add a step in your process so that every time a new certificate is generated, the TLSA records in the DNS are also updated. Note also that DNS TTL values make it so that you should not use a new certificate until it’s guaranteed that everybody has had a chance to see the new TLSA record corresponting to that certificate in the DNS. The normal method for dealing with this is to always have two TLSA records, one for the certificate which you are using, and one for a new certificate which you are not using yet, and make sure that the times are set so that you don’t use the new certificate until the TTL has expired for the resource record set which did not have the TLSA record for that new certificate.

EDIT: Actually, read the response from user “mjl-”; it has more detail, and is obviously from a person which has more practical experience.

First, DANE requires that your DNS is protected with DNSSEC. Your MX records need to be DNSSEC-protected because otherwise any attacker that can give a sender fake MX records can cause an email message to be delivered to a mail server of their choice. The IP lookups to connect to your MX host needs to be DNSSEC-protected, and your TLSA records need to be DNSSEC-protected. For self-hosters, this is usually all the same domain.

Second, your MX host needs DNS records of type TLSA that specify the public keys that are in your TLS certificates that your MX host (mail server) offers during STARTTLS. This is the most common mode for DANE, called DANE-EE (EE = end entity). In this mode, only the public key of the certificate matters. Expiration, hostname match, issuing party of certificates: all ignored. If your MX target is mx.example.com, the TLSA record(s) must be under: _25._tcp.mx.example.com. They will look like this:

3 1 1 5c046ff012891b5f0d6176024c5c25ff486a7c12b8000fdf8b418ab3ecf6d309

3 1 1 cec87fb33d2a7499ca78e824e59b77531ac1fdec7378fc81fce7e5d213a364ab

In these records, "3 1 1" means:

Usage "dane-ee" (3), Selector "spki" (1), Matchtype "sha2-256" (1)

Where spki means "subject public key info", i.e. only the public key matters. So, the last component is the sha2-256 hash of the public key. A mail server can have multiple certificates (e.g. RSA and ECDSA). Each must have a TLSA record.

Keep in mind that when you renew your certificate, you could be reusing your private key or be generating a new private key. A new private key brings a new public key. A new public key requires an updated TLSA record. Keep in mind DNS TTLs in that case. You would have to keep both the old and new TLSA records during the TTL period. I would recommend you don't generate a new private key for each new certificate. If the private key stays the same, the TLSA records don't need to be changed.

MTA-STS requires that the MX host TLS certificate can be verified against the common pool of certificate authorities, i.e. PKIX/WebPKI. DANE and MTA-STS can cooexist. I would recommend setting up both DANE and MTA-STS, using ACME with Let's Encrypt with fixed private keys (not newly generated when fetching a new certificate, I know certbot has an option for this mode), and publishing TLSA records (with the hashes of the public keys of those fixed private keys).

Keep in mind some sending mail servers only implement DANE, and others only MTA-STS. Implementing both gets most protection. Some mail servers implement neither, and are sending email without protection.

> The IP lookups to connect to your MX host needs to be DNSSEC-protected

Really? It does not seem necessary to require this. I mean, the security is guaranteed by the public keys in the TLSA records, right? Yes, the MX lookup and the TLSA lookups must be DNSSEC signed, but does DANE actually require the A/AAAA lookup of the server name in the MX record to also be DNSSEC signed? It does not seem necessary from a security standpoint.

You are correct that it is not needed for security. It is also not required for plain DANE. But it is for DANE for SMTP. The reason is interoperability.

Apparently, some DNS servers would not respond at all to requests for TLSA records (probably fixed in the software by now, but some infra may still run old software). If a sending mail server would request TLSA records, not receive a response, it would have to assume DANE _may_ be required, and abort the delivery attempt. This would lead to mail being undeliverable due to those old DNS servers. Such old DNS servers probably wouldn't be set up for DNSSEC, and with this workaround, the TLSA records wouldn't be requested, so there would be no lookup failure that blocks delivery.

See the paragraphs after the enumeration in https://datatracker.ietf.org/doc/html/rfc7672#section-2.2.2

Oh, right. Thanks for explaining!

Quite a lot of critical responses here.

Personally I think this is a great write-up. Most people in tech these days appear to look down their nose and say 'oh no, you can't host your own mail server anymore'.

This write-up goes to show that it's not as complex as people seem to think.

I'd be curious to see a follow up from the author to address the other claim of this crowd - that the big mail providers mark you as spam due to no existing reputation on the IP, despite all the processes and policy being correct.

This seems risky, Oracle Cloud shuts down VPS they deem to be "inactive", in other words, not under any load or traffic. This would fit that category.

They also shut down the VPSs they deem to be “too active” as in using too much resources, if you’re on the always free tier

Though there are no other cloud hosting providers that give you VPS with public IP and 24GB RAM for free. Oracle did shutdown my VM like 2 times in 3 years, but considering I paid them $0 it's borderline awesome service.

Sounds like you got further than me, they simply permabanned my payment information (also cannot complain too much since i didn’t pay a dime either, but seriously?!)

IDK, their support is pretty responsive and the only requirement they have is that you must sign up using actual credit card and not some prepaid / debit one.

Have you upgrade from the always free plain to the Pay as You Go subscription?

No I did not, but I dont host my mail on their servers either. I still used it quite extensively and it's far more reliable than 99% of cheap cloud providers.

I mostly use them as my personal build server and VPN.

That is the free tier. The fix is very simple. You add a credit card but not go over the free tier usage limits. Then they don't touch your stuff and you still don't pay anything. (Free tier applies to everyone including paying customers)

And then, poof, something goes wrong, Oracle bills you a kilodollar and now you need to fight _Oracle_ if you want any recourse.

No thanks.

Yeh this feels like holding a loaded gun to the head of not only my email but my wallet

You're absolutely right. It can happen.

What can go wrong with a single VM? Billing explosions in the cloud are always to do with auto-scaling services that go wrong. Plus, in that case your alternative is fighting Microsoft, Google or Amazon.

If you run the free tier until the intro period ends you'll know exactly what you can run for free. (There are some free credits during the trial that might skew the resurls) If you do not add anything extra after rhat, there's no visible way you can have a bill larger than 0. But you have to pay attention. Whereas before you would be told "you can't do that", later it'll just go through.

But then Oracle has your credit card number.

Love the intro to self-hosting your email, but aren't you going to be flagged as spam by the main providers anyhow?

You can partially mitigate it by making sure DMARC, DKIM, and SPF are configured right. There are tools online you can use to verify they're setup right, don't remember which sites though.

I have used mxtoolbox.com in the past. However, I don't know how reputed they are.

Note that the 'big mail providers' won't accept your mails even after you apply every known trick in the book. This is especially true for the two biggest ones that provide free services and hosted services on customers domains.

Just off the top of my head, I would suggest using the “Test your email” tool at <https://internet.nl/> for testing incoming e-mail, and <https://www.learndmarc.com/> and <https://www.mail-tester.com/> for testing sending e-mail.

I would also suggest https://www.email-security-scans.org/ for testing outgoing emails.

Others for testing outgoing e-mail which I have saved, but don’t regularly use:

• <https://www.checktls.com/TestReceiver>

• <https://www.helloinbox.email/>

• <http://isnotspam.com/>

If, by “self-host” you mean “hosted by the cheapest VPS I could find, using an IP address range from the wrong side of the metaphorical rail road tracks”, then yes. If by “self-host” you mean “hosted by myself in a server rack in my house, possibly using a VPN to a respected IP connectivity provider”, then no.

I’ve had pretty good luck running my own on digital ocean for several years now.

Actually, I have tested sending mail to Gmail or other Mail Service Provider, and have not found any one flagged my email as spam.

Quite a lot of typos. “platintext”?

> The p= means the police.

Whoop whoop.

Fixed. Sorry, I am not a native english speaker.

More typos: ”Staic”, “domian”, “PRT record”, “fullfill”, “ploice”, and “intrested”.

Fixed, again ;-) thank you very much :)

Lots of singular/plural errors as well. Might run the text through Grammarly or ChatGPT to rectify those.

Asking again here (different thread) but still about email:

Is making email hosting with cute name still a thing? I own a couple of cute domain names (something like love.com or pretty.com, but obviously not those), so I'm thinking if I can do a hotmail on those domains.

Good God, the length of the text ..

Reply on news.ycombinator.com