4 ms·

It's not quite that bad; you can use SMTP over TLS (without the downgradable STARTTLS, plus there's REQUIRETLS now), and there's been plenty of extensions over

It's not quite that bad; you can use SMTP over TLS (without the downgradable STARTTLS, plus there's REQUIRETLS now), and there's been plenty of extensions over the years (like SMTPUTF8). Identity verification has been handled in another layer (the message itself); you could argue that's not the best place, but it is there. And gmail's problems are gmail's problems. The entire world still runs on DNS; as an end-user you can now use DNS-over-HTTPS and that's nice, but that's mostly a frontend for DNS, which as a whole hasn't really been "upgraded". Upgrading SMTP to something new would require upgrading all the world's email servers, otherwise mail.server1.com can't communicate with mail.server2.com. This will probably happen at the same speed as IPv6.

Karrot_Kream 4y ago
Assuming you mean identity verification is handled with GPG keys, nobody actually uses that in practice. Even the people that use Usenet today mostly don't. Email identity is handled de facto by a web of trust anchored by the big domains with no possibility of creating a new trust anchor. You're either managed by Google, Microsoft, or Apple and inherit their trust or you play endless games to not get your mails blocked by default. It's a sad world and didn't need to be this way, but there's no real urge to fix things because the only people who are clamoring to fix email are people who want to encourage folks to use niche experiences like mutt and PRs by mail while the incumbents like Google have no incentive to adopt decentralized trust.
- Beltalowda 4y ago
  Mostly meant SPF/DKIM to verify the sender is authorized to send emails for a particular domain. Verifying that "it is actually the person Karrot_Kream who wrote that email" is harder; but I don't think you can blame that on the SMTP protocol.
cm2187 4y ago
If you create a smtpv2 that can guarantee encryption (ok, who cares) but mostly that guarantees the origin of the email, then the gmails of this world should go softer on classifying those emails as spam, and it won’t take long before only spammers and some forgotten box in a closet are using the old smtp, then its death would be imminent.
- Beltalowda 4y ago
  What do you mean "guarantees the origin of the email" though? That it was you who sent it? That you're allowed to send emails from mymail@example.com? The latter has been solved for some time; the first one is harder, but solvable through GPG or S/MIME, but few seems to have any interest in implementing it. That won't stop anyone from creating a new email address (or mail server) that sends out spam though.
notabee 4y ago
TLS without the certificate verification is still vulnerable to MITM. You get basically the same security level with gpg and plaintext email as you do from email over TLS if someone is trying to MITM. Even this REQUIRETLS that you mention that I didn't know about before looks iffy. If the problem is that upgrading all the world's email servers is too onerous, that still would pretty much have to happen here to support the new smtp extension. DNSSEC for the MX record or this MTA-STS record. It would require each hop in the path to be equally strict in implementing REQUIRETLS unless you want to randomly drop that assurance somewhere in the middle of the route. If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default? Not to mention that as a store and forward protocol, any server hop along the way may store or copy the message at rest in plaintext. If DKIM isn't used to checksum the message, it can be modified too unless there's some mechanism here for that that I'm missing. If every email server needs an infinity gauntlet full of plugins and extensions and DNS records to just have some assurance of the sender's or recipient's validity, how is that really better than just making something new? It's just not made to be a secure protocol. Someone please correct me if I'm misreading the RFC, but can we please, please let smtp die some day?
- dane-pgp 4y ago
  > If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default? The 80:20 solution here might be for the big email providers to declare a flag day (maybe with a 2 year countdown) saying that any email server they connect to after that date has to support TLS, or they will delay the processing of emails to/from that server by 5 minutes, doubling every 6 months. Also, such servers will be named and shamed in their webmail interfaces, so users get a nasty red warning whenever you try to send an email to an affected address or receive one from it. I bet the problem would actually be 99% solved before the flag day even arrived, and most of the remaining 1% would be spam anyway.
- Beltalowda 4y ago
  > TLS without the certificate verification is still vulnerable to MITM. By that standard all of https and ssh are insecure too...
Avamander 4y ago
There's no MUA-STS, there's no good way to enforce TLS for email clients. Most allow errors to be trivially bypassable. MTA-STS between MTA's does help, but IMHO MTA-MTA is not the biggest issue.

Karrot_Kream 4y ago

Assuming you mean identity verification is handled with GPG keys, nobody actually uses that in practice. Even the people that use Usenet today mostly don't. Email identity is handled de facto by a web of trust anchored by the big domains with no possibility of creating a new trust anchor. You're either managed by Google, Microsoft, or Apple and inherit their trust or you play endless games to not get your mails blocked by default. It's a sad world and didn't need to be this way, but there's no real urge to fix things because the only people who are clamoring to fix email are people who want to encourage folks to use niche experiences like mutt and PRs by mail while the incumbents like Google have no incentive to adopt decentralized trust.

Beltalowda 4y ago
Mostly meant SPF/DKIM to verify the sender is authorized to send emails for a particular domain. Verifying that "it is actually the person Karrot_Kream who wrote that email" is harder; but I don't think you can blame that on the SMTP protocol.

cm2187 4y ago

If you create a smtpv2 that can guarantee encryption (ok, who cares) but mostly that guarantees the origin of the email, then the gmails of this world should go softer on classifying those emails as spam, and it won’t take long before only spammers and some forgotten box in a closet are using the old smtp, then its death would be imminent.

Beltalowda 4y ago
What do you mean "guarantees the origin of the email" though? That it was you who sent it? That you're allowed to send emails from mymail@example.com? The latter has been solved for some time; the first one is harder, but solvable through GPG or S/MIME, but few seems to have any interest in implementing it. That won't stop anyone from creating a new email address (or mail server) that sends out spam though.

notabee 4y ago

TLS without the certificate verification is still vulnerable to MITM. You get basically the same security level with gpg and plaintext email as you do from email over TLS if someone is trying to MITM. Even this REQUIRETLS that you mention that I didn't know about before looks iffy. If the problem is that upgrading all the world's email servers is too onerous, that still would pretty much have to happen here to support the new smtp extension. DNSSEC for the MX record or this MTA-STS record. It would require each hop in the path to be equally strict in implementing REQUIRETLS unless you want to randomly drop that assurance somewhere in the middle of the route. If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default? Not to mention that as a store and forward protocol, any server hop along the way may store or copy the message at rest in plaintext. If DKIM isn't used to checksum the message, it can be modified too unless there's some mechanism here for that that I'm missing. If every email server needs an infinity gauntlet full of plugins and extensions and DNS records to just have some assurance of the sender's or recipient's validity, how is that really better than just making something new? It's just not made to be a secure protocol. Someone please correct me if I'm misreading the RFC, but can we please, please let smtp die some day?

dane-pgp 4y ago
> If all the servers have to be updated to do this, is it really that much more difficult to just switch to a new protocol entirely to be secure by default? The 80:20 solution here might be for the big email providers to declare a flag day (maybe with a 2 year countdown) saying that any email server they connect to after that date has to support TLS, or they will delay the processing of emails to/from that server by 5 minutes, doubling every 6 months. Also, such servers will be named and shamed in their webmail interfaces, so users get a nasty red warning whenever you try to send an email to an affected address or receive one from it. I bet the problem would actually be 99% solved before the flag day even arrived, and most of the remaining 1% would be spam anyway.
Beltalowda 4y ago
> TLS without the certificate verification is still vulnerable to MITM. By that standard all of https and ssh are insecure too...

Avamander 4y ago

There's no MUA-STS, there's no good way to enforce TLS for email clients. Most allow errors to be trivially bypassable. MTA-STS between MTA's does help, but IMHO MTA-MTA is not the biggest issue.