The case for self hosting a email server. Is there one?

[Ed.Kloonk]

Seems a single point of failure could be the deleting of your domain name.

 

[james_s]

I knew someone who did this about 20 years ago.

I can't see much reason for it anymore though. If for no other reason, I'd expect most spam filters will block emails coming from some random server.

[2N3055]

Many reasons not to...

[PKTKS]

The necessary 2 cents of jambo...

Old school folks which are deep acquainted in the *NIX culture
will  certainly  clash on any sort of "CLAIMED" *NIX  machine
which does not have one or two email servers readily available..
trusted and operational out of the box.

In the *NIX culture  the machine itself comprises a system
self aware of all the typical services which (like it or not)
are integral part of the Internet itself - besides all the attempts
to privatize these services in faceless corporations..

Examples which are insanely target of replacement by corps...
- FTP      x  shitty drive applets
- CHAT/NEWS   x shitty  zap *gram applets
- EMAIL   x  cloud based web mailers
- HTTP    x  cloud based web hosting
- DNS      x  privatized ip-less managed name servers

- systemV  init and inet starters  x that crappy systemd from the POTTERIX thing..

Old school folks like me never ever set a *NIX system
without **ALL** those services...  being my recent
choices for flat out the box machines...

- ProFTP  very customizable
- CHAT    xchat  and pan
- email    QMAIL  for internal intranet with proper DJB suite
    Postfix  combined for Internet external services
- HTTP   NGINX for external or lighttpd for internal
- DJB  tools  which  do  anything systemd can plus a lot faster and more secure


Please check http://cr.yp.to/djbdns.html  for systemd   server supervisor
or http://cr.yp.to/qmail.html  for QMAIL  absurd fast  server relay...

DJB  DNS resolver is light and faster than BIND... although
BIND is still the most reliable tool you can trust..

The faceless corporations aim to replace the "OLD Internet" with that
combination of things... 

I call that not *NIX  but the POTTERIX py  wayland systemd cloud  thingo...

The more it deviates the *NIX culture the more I don't  want it...

Paul

[PKTKS]

Very interesting side note... TODAY.. just popped this marvelous piece
of non-sense thing .. which obviously raises some questions..

https://www.zdnet.com/article/microsoft-defender-for-linux-now-has-endpoint-detection-and-response-security/

And matches  perfectly the  topic... 

PROTECT? *SERVERS* ? FROM WHOM

The very very same faceless (?) corps which desperately need
to put their buzz models  on top of that  potterix thing..

Who need that crap in the first place ..

Just follow the things pointed above and I doubt a *NIX server
running  FULL BLEEDING EDGE  EMAIL, DNS and FTP services
will EVER NEED THAT SHIT...

Whithout the POTTERIX py systemd thingy there is no chance to put
that shit  inside *NIX...

Paul

[madires]

cons:
- requires experience with MTAs, POP3/IMAP servers, spam filters, ...
- requires time for setup and maintenance

pros:
- can do things no email provider offers
- full control of your side of things

If you set up your mail server correctly only a very few providers block you by default, but usually offer a way to whitelist your server. And MTAs which come with your OS might be not the best choice for an email server, since they often have all features enabled (-> security) and come with limited/strange/cumbersome configuration templates.

[PKTKS]

cons:
(..)
If you set up your mail server correctly only a very few providers block you by default, but usually offer a way to whitelist your server. And MTAs which come with your OS might be not the best choice for an email server, since they often have all features enabled (-> security) and come with limited/strange/cumbersome configuration templates.

You *WILL*  certainly need background on so called MX records....
reason why you **WILL**  mostly need to run your DNS server...

QMAIL  comes by default with ZERO FEATURES..

I am not aware of a more robust and secure suite than
DJB tools...  supervisor, DNS light server and QMAIL absurdly fast relay.

But I would not recommend that for casual or unexperienced folks...

A steep step but after that there is no coming back.
Once you have deployed the tools a couple times is piece of cake..

Paul

[madires]

You *WILL*  certainly need background on so called MX records....

The important point is to have matching entries for forward and reverse mapping.

reason why you **WILL**  mostly need to run your DNS server...

Many hosters/providers offer a web-based DNS management allowing you to fully customize DNS settings for your domains. Running your own nameservers isn't necessary. And reverse mapping is done by the hoster/provider anyway.

A steep step but after that there is no coming back.
Once you have deployed the tools a couple times is piece of cake..

Can't argue with that.

[ve7xen]

The existence of the domain name is orthogonal to hosting your own mail...

I would certainly advise that anyone that cares about their e-mail address own their domain name themselves, and not use a 'free' or otherwise 3rd-party domain. If your e-mail address is tied to a particular provider, so too are you. They may later change their terms, decide to sunset the service, go out of business etc. and then you will have a difficult decision to make. If you own the domain name yourself, you can easily move providers as you choose, without affecting your reachability, even if you don't self-host.

As far as hosting it yourself, there are some advantages, such as being able to investigate delivery failures yourself, and knowing that your e-mail isn't being mined or shared en masse with law enforcement without your consent, and flexibility to run scripts against your mail or whatever else you might want. For most people these days though I would suggest you just pay a nominal fee to have your mail hosted by a company that focuses on doing that. It isn't that hard to set up a properly secure mail server, but if you don't know what you're doing, and even if you do, it's a significant amount of effort to do it properly vs. paying Fastmail (which I heartily recommend) or similar $5/month. I host my own because I have the server for other reasons, and because of inertia after doing so for 20 years, but I would just pay someone if not for that.

[Ed.Kloonk]

The existence of the domain name is orthogonal to hosting your own mail...

I would certainly advise that anyone that cares about their e-mail address own their domain name themselves, and not use a 'free' or otherwise 3rd-party domain. If your e-mail address is tied to a particular provider, so too are you. They may later change their terms, decide to sunset the service, go out of business etc. and then you will have a difficult decision to make. If you own the domain name yourself, you can easily move providers as you choose, without affecting your reachability, even if you don't self-host.

As far as hosting it yourself, there are some advantages, such as being able to investigate delivery failures yourself, and knowing that your e-mail isn't being mined or shared en masse with law enforcement without your consent, and flexibility to run scripts against your mail or whatever else you might want. For most people these days though I would suggest you just pay a nominal fee to have your mail hosted by a company that focuses on doing that. It isn't that hard to set up a properly secure mail server, but if you don't know what you're doing, and even if you do, it's a significant amount of effort to do it properly vs. paying Fastmail (which I heartily recommend) or similar $5/month. I host my own because I have the server for other reasons, and because of inertia after doing so for 20 years, but I would just pay someone if not for that.

Fastmail is a U.S. company is it not? Just as with a U.S. registered domain, the company can pull the rug out and I have no consumer protection.

[ve7xen]

I believe it's Australian, actually, but they definitely have servers in the US. But that wasn't really the point, you can choose a provider that meets whatever criteria you set, and one of those can be country of incorporation or data sovereignty. I am sure there are professional mail hosts that operate wholly within Australia, as there are domain registrars, if that's what you're looking for. You can even use a .(com|id).au domain if you prefer to completely remove any potential influence of the US.

And the bottom line is that even if Fastmail were to screw you over somehow, you would still own the domain and can easily switch providers.

[Syntax Error]

@Ed.Kloonk The biggest advantage of using a mail host server is their secure socket connection. If you wanted to secure your own email server, you would need to buy or at least 'fake' your own server certificate. Another advantage is, not requiring DNS forwarding to your own 'domestic' IP address. If you're a medium sized business, then it makes perfect sense to add a mail server to the racking cabinet. And hire a guy to stress over the hardware and software settings. Otherwise, stick to using a mail host; but retain 100% control over your email accounts(and forwards) by having your own domain name - which should expire in a good five years time (hint for newbies). One last point, know where the email service is physically geolocated; what's on that server comes under the data rules of that jurisdiction. Not too clever having a Russian email service if, for example, you're a member of Congress.

[Cerebus]

@Ed.Kloonk The biggest advantage of using a mail host server is their secure socket connection. If you wanted to secure your own email server, you would need to buy or at least 'fake' your own server certificate. Another advantage is, not requiring DNS forwarding to your own 'domestic' IP address.

Wrong on both points.

Getting a free valid SSL certificate from LetsEncrypt has been trivial to do for several years. You don't need some other service provider to make use of their "secure socket connection". As it is the vast majority of email travels unencrypted, not touching an SSL socket at all (although that's getting better). Even when you do get a secured SMTP connection, 99% of the time the server at the remote end is using a bullshit self-signed certificate - including from organisations that ought to know better and use a proper traceable SSL certificate. Vis, email received from US CERT today:

Return-Path: <messages@ncas.us-cert.gov>
Received: from mailer086149.service.govdelivery.com (mailer086149.service.govdelivery.com [69.5.86.149])
   by <MYMAILSERVER> (8.15.2/8.15.2/Debian-8+deb9u1) with ESMTPS id 10DLGN08009920
   (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO)
   for <MYMAILACCOUNT>; Wed, 13 Jan 2021 21:16:30 GMT

What is this "requiring DNS forwarding to your own 'domestic' IP address." thing you speak of? Not something I've ever had to do, or frankly even understand what you think you mean. "DNS forwarding" in that context is not something that makes sense to me, and I was running ISPs networks from 1995 onwards, so I'm not exactly an IP networking neophyte. I'm guessing you're talking about using some sort of external dynamic DNS service - no "forwarding" going on there, just dynamic updates to A records.


You'll need a fixed IP address to serve anything in a sensible fashion, and you won't get that from the average consumer ISP, who will most likely ban you from running a mailserver anyway. Have a mailserver that keeps changing its IP address because of using dynamic IP addresses and I guarantee that you'll be on the block lists of all the large email service providers marked as as 'untrusted' in no time at all and they'll all refuse mail from you. So, forget the typical big consumer ISPs and find a small but stable outfit that hands out fixed IP addresses if you want to run a server from home (For the UK I cannot recommend A&A too highly).

That is probably the biggest barrier, after the necessary knowledge, to running your own mail server from home. The obvious alternative would be to pay for a small virtual server hosted on some service provider's network. You only need the most minimal server to run a domestic scale mail server - mine's been running on a 2Gb Core Duo machine with an 80Gb disk for years - the tiniest option from a service provider would be enough.

I've been running my own personal mail server since 1996, initially on a machine colocated on one of the nets I managed, then from 2003 to 2006 on a colocated server at a third party ISP, and since 2006 to present on a DSL line at home. There's not much to it if you know the basics. All the work is in initial configuration and I think I have to dip in and adjust or actively manage something less than once a year. From my perspective it's no effort at all, barely worth mentioning.

The benefits of doing so include: I have complete control on what I send and receive. I can create and delete arbitrary mail accounts at whim (within the domains I control). I can block or permit mail from outside entities at will, not be dictated to by some third party's policies. I can create a new, unique email address for every web form that I have to fill in, every online account I'm forced to create and when the inevitable spam arrives I have precise proof of who leaked my details to the spammer. When things go wrong I have the logs to examine myself, I don't have to rely on some Pimply Faced Youth in first line support at some faceless mega-corp who hasn't a clue what he's doing and a script that includes "Have you rebooted the router?".

Because I also run my own primary and resolving DNS servers I'm not subject to the whims of my government trying to censor things via DNS (it also means that no facebook owned domain even resolves on my network, they were banned from my digital life years ago as soon as it became clear what a bunch of bastards they are).

[ve7xen]

Getting a free valid SSL certificate from LetsEncrypt has been trivial to do for several years. You don't need some other service provider to make use of their "secure socket connection". As it is the vast majority of email travels unencrypted, not touching an SSL socket at all (although that's getting better). Even when you do get a secured SMTP connection, 99% of the time the server at the remote end is using a bullshit self-signed certificate - including from organisations that ought to know better and use a proper traceable SSL certificate. Vis, email received from US CERT today:

On the mail platform I administer at least, of about 90,000 messages today, only about 6,000 were delivered to us unencrypted. The vast majority of mailboxes are on large mail providers that are all doing opportunistic TLS these days. Also, unless you explicitly configure your server to request them, client certificates won't be sent (to which almost all SMTP servers in the wild wouldn't have a certificate to send in answer), so you wouldn't expect an inbound connection to ever be verified, since certificates are typically only exchanged server -> client.

I'm not sure PKI has a lot of value for SMTP, and it creates a lot of problems. SMTP provides no mechanism for signalling the 'expected' server hostname, so the SMTP client doesn't have anything to verify the identity against, and while the server may be able to verify the client's identity against the envelope domain or something, this creates problems since SMTP doesn't make assumptions about the server knowing anything about the sending or recipient domain at all (it may be a relay somewhere on the path), in which case what hostname do you verify against? In most cases a practical solution to this conundrum is going to mean that the certificate holder also controls the name that is being validated against, which means it is worthless. We'd have to redesign SMTP to get around it, I think. In the meantime, doing *any* encryption is substantially better than none.

But this is getting into the weeds. Your main point is correct - you do not need to be beholden to anyone to have strong crypto for your e-mail, even if you don't use Let's Encrypt. Nobody does certificate verification in SMTP anyway, so you don't lose anything meaningful by using a self-signed certificate.

[sleemanj]

DIY mail server in 2021?  No.

Just pay Microsoft or Google or Zoho or... a few bucks a month and host your mail accounts there.

If you want to send transactional mail from server, for low volumes, again just run it through your Microsoft/Google/Zoho/... account's SMTP server or use a transactional handler like Mailgun.

[Cerebus]

Getting a free valid SSL certificate from LetsEncrypt has been trivial to do for several years. You don't need some other service provider to make use of their "secure socket connection". As it is the vast majority of email travels unencrypted, not touching an SSL socket at all (although that's getting better). Even when you do get a secured SMTP connection, 99% of the time the server at the remote end is using a bullshit self-signed certificate - including from organisations that ought to know better and use a proper traceable SSL certificate. Vis, email received from US CERT today:

On the mail platform I administer at least, of about 90,000 messages today, only about 6,000 were delivered to us unencrypted. The vast majority of mailboxes are on large mail providers that are all doing opportunistic TLS these days. Also, unless you explicitly configure your server to request them, client certificates won't be sent (to which almost all SMTP servers in the wild wouldn't have a certificate to send in answer), so you wouldn't expect an inbound connection to ever be verified, since certificates are typically only exchanged server -> client.

Think again:

Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.4])
   by <MYMAILSERVER> (8.15.2/8.15.2/Debian-8) with ESMTPS id wA2FGSFq005671
   (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK)
   for <MYEMAILADDRESS>; Fri, 2 Nov 2018 15:16:30 GMT

Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20:0:0:0:b32])
   by <MYMAILSERVER> (8.15.2/8.15.2/Debian-8) with ESMTPS id w9GCxl8X018260
   (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK)
   for <MYEMAILADDRESS>; Tue, 16 Oct 2018 13:59:49 +0100

Received: from smtpi.msn.com (ch1gmehub14.msn.com [207.46.200.24])
   by <MYMAILSERVER> (8.15.2/8.15.2/Debian-8) with ESMTPS id 036J29w7020047
   (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=OK)
   for <MYEMAILADDRESS>; Mon, 6 Apr 2020 20:02:12 +0100

Getting a verify=OK tells you that the remote server is indeed who it claims to be and that you're not getting MITMed and intrinsically means that the far end SMTP server (acting as client) had to present a certificate to my SMTP server to be verified. Opportunistic encryption with self-signed certificates, rather than CA signed certificates, tells you nothing. I could, if I wish, configure my server to always require a particular certificate, or a certificate with a particular root CA, for traffic from Messagelabs, Google, Microsoft (yes, it surprised me too) and the other handful of people who do this properly, and refuse connections if they appeared to be being MITMed, but it's really not worth the bother. I do have rules set up for some colleagues/partners who run TLS (strictly STARTLS) properly on their servers to require a correct certificate before accepting the connection (or more accurately, it's set up to reject the connection if it gets a hooky certificate).

[ve7xen]

Getting a verify=OK tells you that the remote server is indeed who it claims to be and that you're not getting MITMed and intrinsically means that the far end SMTP server (acting as client) had to present a certificate to my SMTP server to be verified. Opportunistic encryption with self-signed certificates, rather than CA signed certificates, tells you nothing. I could, if I wish, configure my server to always require a particular certificate, or a certificate with a particular root CA, for traffic from Messagelabs, Google, Microsoft (yes, it surprised me too) and the other handful of people who do this properly, and refuse connections if they appeared to be being MITMed, but it's really not worth the bother. I do have rules set up for some colleagues/partners who run TLS (strictly STARTLS) properly on their servers to require a correct certificate before accepting the connection (or more accurately, it's set up to reject the connection if it gets a hooky certificate).

Even if you request them, all it tells you is whether or not the cert chains up to an authority you trust. But you don't really care about that with e-mail, since it is the sender and recipient addresses that you would care about verifying the SMTP server you are talking to has some sort of authority to handle, but there is no existing mechanism to do that. There is nothing stopping a spoofed server from presenting a valid, CA-signed certificate which you will accept, and a hypothetical MITM can just as easily forge SPF or PTR which you might propose using to try to validate the identity of the server against the sending domain. Server name doesn't appear to the user as part of the identity of the message, though, so it's kind of irrelevant whether its identity is established or not; it would be far easier to just use a different 'unprivileged' server name in your 'attack', which you can produce valid certificates for, and from the MUA side it will look effectively identical.

You can of course manually configure this against a particular domains to verify against a particular CA or certificate if you really want to. The problem is that there is currently no systematic way to enable this, so everyone must use opportunistic TLS with SMTP to continue to ensure interoperability. But I don't think it adds much value anyway, because the identity you care about is that of the e-mail address, not the server, and you more or less need to do *that* identity verification at the application layer (ie PGP, S/MIME or less-strongly DKIM), at least with the way SMTP is currently structured.

Almost all MTAs in the real world will just fall back to plaintext SMTP if TLS negotiation fails, so there is negative value in rejecting connections that fail verification or don't support strong ciphers or whatever without negotiating this policy with the counterpart, and that's not practical at scale.

[SVFeingold]

If your e-mail address is tied to a particular provider, so too are you. They may later change their terms, decide to sunset the service, go out of business etc. and then you will have a difficult decision to make. If you own the domain name yourself, you can easily move providers as you choose, without affecting your reachability, even if you don't self-host.

This is one of those things like...people squirreling all their data away in an external HDD in their closet (and/or a safe deposit box) because they don't trust Microsoft or AWS to keep their data safe. It's more work and in the majority of cases, ultimately still less secure. There's definitely an argument here when it comes to the fly-by-night or smaller providers. But the big behemoths that basically run the internet? They aren't just going to "go away." It's such a weird argument IMO. "What if they just shut it off for fun!" I dunno, what if Chinese hackers brick your closet server? And in any case there is no point to e-mail if you are the only one on the network. As you don't - and can't - control basically any of it beyond the hardware in your own home. You're entirely dependent on these entities no matter what you do. Who maintains the trunklines? The datacenters? The DNS servers? The switching equipment? Not you!

...knowing that your e-mail isn't being mined or shared en masse with law enforcement without your consent

Can you know this though? I feel like we've yet to discover even a fraction of what the NSA and other organizations are capable of doing (and what agreements they have with providers of both software and hardware...) I'm not really up to speed on email delivery protocols. You can't do end-to-end encryption unilaterally. AFAIK none of the major providers are truly end-to-end encrypted by default. My understanding is that unless you only communicate with other people who have a mutually agreed upon encryption scheme independent of any of the email providers, they can probably still read all your comms just fine.

Not to say that there's no reason. Many times it seems like people get the idea they'll be able to easily make a more secure and reliable server than Google or Apple or Amazon. If I were to bet, I'd bet that 99% of the time they're wrong. Especially if you're not actually trying to host it yourself but buying/renting a server in a datacenter.

Anyway, ignore me, I'm just thinking out loud.

[ve7xen]

This is one of those things like...people squirreling all their data away in an external HDD in their closet (and/or a safe deposit box) because they don't trust Microsoft or AWS to keep their data safe. It's more work and in the majority of cases, ultimately still less secure. There's definitely an argument here when it comes to the fly-by-night or smaller providers. But the big behemoths that basically run the internet? They aren't just going to "go away." It's such a weird argument IMO. "What if they just shut it off for fun!" I dunno, what if Chinese hackers brick your closet server?

They aren't going to go away overnight, but the terms of service regularly change, and services (especially free ones) are regularly sunset. Or maybe you just decide you don't like it anymore because they change the UI (which happens frequently), or they change their pricing, or you don't like the implications of their privacy policy any more, or they lose/expose your (or other users') data, or you get fed up with outages, or some shiny new feature isn't available, or or or or or. There are endless reasons why you might want to or be forced to switch providers. It's very considerably less painful to do so if you own the domain and thus the address you printed on your business cards, website, and truck wrap and that is in all your contacts' address books. When I used to do tech support for small businesses, this pain came up all the time for one reason or another. Give yourself the option. You can still pay most of those companies to host mail on your own domain if you like their service. I definitely don't suggest the average person try to DIY.

I had written a long response on the security side, but I don't want to drag the thread any further OT than I already have. Bottom line is that if you operate it, you have a much better picture of who is accessing your data than if you don't, Google et. al. are much bigger targets both for attackers and law enforcement dredging operations, and for many people they aren't on your side, so handing the data directly to them was never an option.

[Cerebus]

Getting a verify=OK tells you that the remote server is indeed who it claims to be and that you're not getting MITMed and intrinsically means that the far end SMTP server (acting as client) had to present a certificate to my SMTP server to be verified. Opportunistic encryption with self-signed certificates, rather than CA signed certificates, tells you nothing. I could, if I wish, configure my server to always require a particular certificate, or a certificate with a particular root CA, for traffic from Messagelabs, Google, Microsoft (yes, it surprised me too) and the other handful of people who do this properly, and refuse connections if they appeared to be being MITMed, but it's really not worth the bother. I do have rules set up for some colleagues/partners who run TLS (strictly STARTLS) properly on their servers to require a correct certificate before accepting the connection (or more accurately, it's set up to reject the connection if it gets a hooky certificate).

Even if you request them, all it tells you is whether or not the cert chains up to an authority you trust. But you don't really care about that with e-mail, since it is the sender and recipient addresses that you would care about verifying the SMTP server you are talking to has some sort of authority to handle, but there is no existing mechanism to do that. There is nothing stopping a spoofed server from presenting a valid, CA-signed certificate which you will accept, and a hypothetical MITM can just as easily forge SPF or PTR which you might propose using to try to validate the identity of the server against the sending domain. Server name doesn't appear to the user as part of the identity of the message, though, so it's kind of irrelevant whether its identity is established or not; it would be far easier to just use a different 'unprivileged' server name in your 'attack', which you can produce valid certificates for, and from the MUA side it will look effectively identical.

You seem to know of SPF but apparently not DNSEC, which makes SPF or PTR forgery rather hard to successfully do and people together enough to deploy CA backed certificates are also together enough to inplement DNSSEC. You're effectively arguing against using STARTLS properly because it doesn't offer end-to-end authenticity guarantees between two users - which is true. You're ignoring defence in depth, which STARTLS is a useful part of. If you don't bother to use S/MIME or PGP, which most people don't, opportunistic encryption with a self-signed certificate offers a certain amount of probabilistic privacy protection and no authenticity protection worth mentioning. Using STARTLS with proper CA backed PKI rather than essentially meaningless self signed certificates offers more privacy and authenticity guarantees.

Yes, the CA backed PKI is only as trustworthy as the CA is, but I'll bet you regularly hand over financial information and more on the strength of a CA backed certificate verifying the authenticity of a web site. The guarantees of authenticity and privacy of server to server traffic over SMTP using CA backed certificates are exactly the same as those you get visiting a secure website over HTTPS, it's the same certificates, it's the same TLS protocol. In both cases you're better off with an encrypted channel over a plaintext one, and better off still with a pukka CA backed certificate over a self-signed one.

[Syntax Error]

OP, I was going to write a ten thousand world dissertation on TLS and the CA root authority, but other's have already done this.

Data centers are invested in security. Although they may be the NSA in disguise, your data is safer somewhere in the cloud than on a Rasberry Pi next to the ISPs stock router. It's not the Chinese state or those Fancy Bear's that are the threat to personal users, but rather, malicious 'hobby' hackers who will cause a lot of trouble for private citizens, with little or no retribution.

For self-hosting, be sure any funky color changing IoT light bulbs are not on the same network segment as the self-signed TLS mail, web or media server.

[PKTKS]

I am following rather curious the comments...

And one thing that is clear crystal is that ...

- complete well deployed hosts on ** INTRANET ** exchange email...
- that is not related with external email services.

If you have a SOHO with a dozen machines chances are you  ** WILL ** need:
- a proper DNS deployed for your intranet exchange.
- proper email servers   for  machine interchange
- proper supervisor for 24hr dead time service.

And ** IF **  you have all that already setup... chances are you
will just need to deploy a simple external MTA  (like Postfix)

then it make sense to have proper DNS records (MX) published
and of course a proper certificate to your domain.

2 different complementary scenarios

and yes that is still very needed in 2021... 2022... 
INTRANET  SOHO of small buzz still need machine servers..

It not just like .. hey subscribe that account from xxxx

Paul

[madires]

I wouldn't recommend to run a mail server at home if your internet access has dynamic IP addresses. Most mail servers verify the reverse mapping and many also block prefixes used for dynamic address pools, because they are the common source of bot generated SPAM. In that case your mail server could only receive email from the internet and needs a smarthost or mail relay for sending. Another solution would be a tunnel to a server with a fixed IP address.

[PKTKS]

I wouldn't recommend to run a mail server at home if your internet access has dynamic IP addresses. Most mail servers verify the reverse mapping and many also block prefixes used for dynamic address pools, because they are the common source of bot generated SPAM. In that case your mail server could only receive email from the internet and needs a smarthost or mail relay for sending. Another solution would be a tunnel to a server with a fixed IP address.

In the simplest possible case you have a machine (e.g. a PC) directly
wired to the provider (cable modem, antenna  ...whatever)

In that case you may not have the will to setup  a dual binded
interface to isolate the external provider  and your machine...

But IMHO definitely everybody should do so.

The more common case is where you interface a WAN port
(in which a WAN IP apply) with  CIDR machines ... in which
you have absolute control over all those problems.

The interfaces (or VLAN) isolate networks and keep things
properly sane and safe..

Less common case where you have some CIDR hosts
mixed in some WAN across a VLAN.. 

Nevertheless  the latter is a combination of first two
and  you can keep  a strong email server (like QMAIL)
running unattended just fine..

Done that several times.  Bonded interfaces across VLANs
can solve rather complex safety issues

Paul

[ve7xen]

You seem to know of SPF but apparently not DNSEC, which makes SPF or PTR forgery rather hard to successfully do and people together enough to deploy CA backed certificates are also together enough to inplement DNSSEC. You're effectively arguing against using STARTLS properly because it doesn't offer end-to-end authenticity guarantees between two users - which is true. You're ignoring defence in depth, which STARTLS is a useful part of. If you don't bother to use S/MIME or PGP, which most people don't, opportunistic encryption with a self-signed certificate offers a certain amount of probabilistic privacy protection and no authenticity protection worth mentioning. Using STARTLS with proper CA backed PKI rather than essentially meaningless self signed certificates offers more privacy and authenticity guarantees.

Of course I am aware of DNSSEC. It is not widely deployed on the authority side, and it is only resistant to MITM if the attacker is not also able to manipulate traffic between the DNS resolver the recursor, and it is not resistant at all against DOS. Which means the attacker can cause SPF or PTR record lookups to fail entirely, and you guessed it - fall back to 'unprotected' delivery. You miss the fundamental problem, which is that SMTP doesn't couple the address and server identities. So you know it matches the authority of the PTR record - that tells you nothing, the PTR could be spybox.kgb.ru, and your MTA will faithfully accept that as long as it chains up to a trusted CA. But SPF you say! Well, first of all this only protects the envelope sender address, which isn't generally visible to users anyway, so is pretty much irrelevant. Secondly, even if you only accept name-based SPF records, nobody provides any guarantee that their legitimate MTAs will offer a CA signed client certificate, so you can't depend on this at scale, which means - you guessed it - you have to fall back to plaintext or accept it anyway. Maybe you use it for a spam score or something, but it isn't usable for much.

Would it be possible to design improvements? Sure, but they don't exist today, and even if they did exist, you still need to encrypt end to end at the application layer anyway, so what is the point. Knowing the identity of the server is what it says it is doesn't do anything for e-mail security.

The fundamental flaw to any attempt to strenghten this is that in pretty much any scenario it is trivial to force the connection to be completely plaintext and all of this is meaningless, especially when you're talking about client certificates. A malicious client is just going to connect to you in plaintext. Transit encryption basically only protects from sniffing, and in that scenario you are protected whether you use a signed certificate or not.

Yes, the CA backed PKI is only as trustworthy as the CA is, but I'll bet you regularly hand over financial information and more on the strength of a CA backed certificate verifying the authenticity of a web site. The guarantees of authenticity and privacy of server to server traffic over SMTP using CA backed certificates are exactly the same as those you get visiting a secure website over HTTPS, it's the same certificates, it's the same TLS protocol. In both cases you're better off with an encrypted channel over a plaintext one, and better off still with a pukka CA backed certificate over a self-signed one.

This is a very different scenario where you are verifying the actual identity of a party you are contacting is what it says it is, end-to-end. That is meaningless in the context of e-mail because the server identity and the user identity are only loosely coupled, and there is no strongly verifiable way to couple them. It is all about inertia, and if we had the option to redesign it from scratch, many things would be different, this among them. As long as we continue using SMTP though, it will be trivial for almost any attack scenario to simply degrade to plaintext if any issues with certificates or otherwise with encryption are encountered. Because of legacy, MTAs must support this. The only exception would be specifically negotiated (or published) policies to do otherwise, which is not widely applicable, and in that case you can probably anchor it at a particular CA and still not care about the public PKI.

I'm not arguing against going to the trouble of getting signed certificates for your MTAs and matching them with PTR names and HELO names, it just has very little security value. What I would argue is against strict TLS policies on your mail servers, because all you will do is cause a greater proportion of your connections to revert to plaintext, which has negative security value.