Nowdays client-server and server-server communication is ecrypted and signed, so no an issue now.
This is probably true, but in a very unsatisfying way. It’s not accurate to say this is not an issue now because mail servers talk to each other with opportunistic encryption — if both ends say “hey, I support TLS” they’ll talk over TLS, but if either end claims to not support TLS they’ll default to plain text. This is deeply concerning because it’s very possible for somebody to mimic another server and get the connection downgraded to plain text, bypassing TLS altogether. There are standards to deal with this, like DANE, but most large e-mail providers don’t support this… The other more recent standard to address this is called MTA-STS, but it’s much weaker than DANE and can potentially be exploited (but at least gmail and outlook support it, I guess). E-mail security is in a weird place. It’s slightly better than the “completely unencrypted” situation that people seem to think it is… But it’s also pretty much impossible to guarantee that your e-mail will not be sent over plain text.
AFAIK DKIM/DMARC now is mandatory on most servers.
DKIM and DMARC don’t have anything to do with this. DKIM is a way for e-mail servers to sign e-mails with a key that’s placed in DNS in an attempt to prevent e-mail spoofing, but this in no way protects e-mails you send from potentially being read in plain text. DKIM is also not necessarily mandatory, and you can potentially get away with just SPF. Many mail servers also do not have strict sender policies, which could potentially allow for spoofing in certain situations. Also neither DKIM / SPF provide any protections if an attacker is able to poison DNS records.
GPG. Or other E2EE.
I mean, yes, but that’s not really the point. PGP has essentially nothing to do with the e-mail protocols aside from the S/MIME extensions. Almost no institution is using PGP to secure e-mails. You could also encrypt something using PGP before you sent it over the fax lines in theory.
Neither TLS provide in such case. Attacker can request ACME cert.
Depends whose DNS you can mess with, but yes! It may be possible to poison DNS records for one e-mail server, but ACME certificate providers like letsencrypt (supposedly) try to do DNS lookups from multiple locations (so hopefully a simple man-in-the-middle attack will not be sufficient), and they do lookups directly from the authoritative DNS servers. This is, of course, not perfect and theoretically suffers from all of the same mitm problems, but it’s more thorough than most mail servers will be and would potentially limit who would be in the position to perform these attacks and get a bogus certificate issued.
With DNSSEC and DANE you are even able to specify which TLS certificate should be used for a service in a TLSA record, and you can protect your A records and your CAA record which should make it much harder to get bogus certificates issued. Of course you need to trust the TLDs in order to trust DNSSEC, but you already do implicitly (as you point out, if you control the TLD you can get whatever certificate you want issued through ACME). The reality right now is that all trust on the web ultimately stems from the TLDs and DNS, but the current situation with CAs introduces several potential attack vectors. The internet is certainly a lot more secure than it used to be even 10 years ago, but I think there’s still a lot of work to be done. DNSSEC, or something like it, would go a long way to solving some of the remaining issues.
This is probably true, but in a very unsatisfying way. It’s not accurate to say this is not an issue now because mail servers talk to each other with opportunistic encryption — if both ends say “hey, I support TLS” they’ll talk over TLS, but if either end claims to not support TLS they’ll default to plain text. This is deeply concerning because it’s very possible for somebody to mimic another server and get the connection downgraded to plain text, bypassing TLS altogether. There are standards to deal with this, like DANE, but most large e-mail providers don’t support this… The other more recent standard to address this is called MTA-STS, but it’s much weaker than DANE and can potentially be exploited (but at least gmail and outlook support it, I guess). E-mail security is in a weird place. It’s slightly better than the “completely unencrypted” situation that people seem to think it is… But it’s also pretty much impossible to guarantee that your e-mail will not be sent over plain text.
AFAIK DKIM/DMARC now is mandatory on most servers.
GPG. Or other E2EE.
DKIM and DMARC don’t have anything to do with this. DKIM is a way for e-mail servers to sign e-mails with a key that’s placed in DNS in an attempt to prevent e-mail spoofing, but this in no way protects e-mails you send from potentially being read in plain text. DKIM is also not necessarily mandatory, and you can potentially get away with just SPF. Many mail servers also do not have strict sender policies, which could potentially allow for spoofing in certain situations. Also neither DKIM / SPF provide any protections if an attacker is able to poison DNS records.
I mean, yes, but that’s not really the point. PGP has essentially nothing to do with the e-mail protocols aside from the S/MIME extensions. Almost no institution is using PGP to secure e-mails. You could also encrypt something using PGP before you sent it over the fax lines in theory.
Neither TLS provide in such case. Attacker can request ACME cert.
Depends whose DNS you can mess with, but yes! It may be possible to poison DNS records for one e-mail server, but ACME certificate providers like letsencrypt (supposedly) try to do DNS lookups from multiple locations (so hopefully a simple man-in-the-middle attack will not be sufficient), and they do lookups directly from the authoritative DNS servers. This is, of course, not perfect and theoretically suffers from all of the same mitm problems, but it’s more thorough than most mail servers will be and would potentially limit who would be in the position to perform these attacks and get a bogus certificate issued.
With DNSSEC and DANE you are even able to specify which TLS certificate should be used for a service in a TLSA record, and you can protect your A records and your CAA record which should make it much harder to get bogus certificates issued. Of course you need to trust the TLDs in order to trust DNSSEC, but you already do implicitly (as you point out, if you control the TLD you can get whatever certificate you want issued through ACME). The reality right now is that all trust on the web ultimately stems from the TLDs and DNS, but the current situation with CAs introduces several potential attack vectors. The internet is certainly a lot more secure than it used to be even 10 years ago, but I think there’s still a lot of work to be done. DNSSEC, or something like it, would go a long way to solving some of the remaining issues.