Selfhosted Email by Maddy on Oracle Cloud(taoshu.in) |
Selfhosted Email by Maddy on Oracle Cloud(taoshu.in) |
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.
Note: There’s an easier, more canonical way to do that:
apt install build-essentialI thought RainLoop was the new hot thing. (<https://www.rainloop.net/>)
Covering MTA-STS is practical. The fact they do so wins them points towards having built something that works in the real world.
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.
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.
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.
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.
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.
> The p= means the police.
Whoop whoop.
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.
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.
• <https://www.checktls.com/TestReceiver>
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.
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
I mostly use them as my personal build server and VPN.