5 ms·

This is far too little, too late: * The SMTP RFC says that mail servers MUST NOT require STARTTLS to receive mail. Postfix (and I imagine most other production

This is far too little, too late: * The SMTP RFC says that mail servers MUST NOT require STARTTLS to receive mail. Postfix (and I imagine most other production grade SMTP servers) has an option to require STARTTLS anyway, so if you really want STARTTLS you can already require that clients have it enabled, despite the braindead standard. * STARTTLS ensures that mail was encrypted only in the final hop, from the last server to your server. That usually means it transited the public internet encrypted, but it definitely does not assure it. There are interesting email security efforts afoot, notably the draft standard called "SMTP Require TLS": https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-02 https://tools.ietf.org/html/draft-ietf-uta-smtp-require-tls-... . Unfortunately the reality is that the internet mail infrastructure evolves at an incredibly glacial pace. The entire SMTP protocol would benefit greatly from the adoption of an SMTP/2 protocol, rethought with modern security practices in mind.

devereaux 8y ago
I fully agree. It will not achieve anything. FYI, "SMTP Require TLS" was running on port 465 many years ago. With many ISPs (and even some VPS) now blocking port 25, it could have been an opportunity to migrate naturally towards the "new" unencumbered port.
schoen 8y ago
Please see my reply downthread: https://news.ycombinator.com/item?id=17397816 https://news.ycombinator.com/item?id=17397816
ubernostrum 8y ago
The SMTP RFC says that mail servers MUST NOT The email RFCs require supporting a lot of things that are now horrendously outdated, and forbid doing a lot of things that should now be best practices. The RFCs should lose that battle.
- axaxs 8y ago
  See, at surface value I agree. But at a deeper level I don't. The problem is too many broken protocols exist via RFC only (dns, smtp, etc). Rather than violate that, or force it into something it's not, we should be writing newer, better protocols. The friction against this is huge, mainly by those who capped out at the previous RFCs, though. Email(well, smtp) itself is so outdated and broken, I can't believe it's still so widely used.
  - JdeBP 8y ago
    IM2000 protocols have already been written. (-: * http://jdebp.eu./Proposals/IM2000/ http://jdebp.eu./Proposals/IM2000/ But of course you are already using a pull-style messaging system, that is right in front of you. * https://news.ycombinator.com/item?id=10405864 https://news.ycombinator.com/item?id=10405864
    - axaxs 8y ago
      Fair point, but I was thinking something like Signal, WhatsApp, or the like. So, I like to think of email as a bit dated, not only in security but in model. That said, the beauty of email is that you have a unique identifier that doesn't force the other party into your walled garden. If we could develop something akin to Signal, but that didn't require the second party to have to sign up explicitly for that service, I think that could finally start the process. Which, of course, would also require some level of initial adoption, probably the hard part.
  - avaika 8y ago
    smtp might be broken, but it would be extremely hard to replace it to something incompatible, as it's a very core of the nowadays internet. Moreover it has the advantage no other popular communication service has: people somehow managed to agree on protocol standard so anyone is able to run own smtp server. In modern days of huge corporations a new popular standard like this seems impossible.
cm2187 8y ago
How did these committees think that optional, downgradable encryption was preferable to a standalone, encrypted only port (465)? Were they trying to save server ports, like if it was a precious resource? Any design decision I have seen regarding email since 2000 defies common sense. Like I heard most SMTP implementations do not validate certificates. What good is an unvalidated certificate? SPF is treated as indicative only or ignored. We are managing to replace http1.1 with http2, it will take time but it is on the way. I am not even aware that an actual SMTP2 draft protocol that would solve all these design flaws (unverified sender, unencrypted). And SMTP has a benefit http didn’t have. Most people access their emails through webmails, smartphones or enterprise outlook/exchange servers. For webmails and exchange only the server needs to be updated, and for smartphones, their short life ensures that older versions are pretty much all retired within 5 years. In addition, a handful of big players (google yahoo apple msft) have such a concentration of recipient accounts (retail users) that they can force a change on the market with the threat of your mail being classified as junk by them. So we could achieve a pretty quick transition.
- JdeBP 8y ago
  The same has been pointed out about Web browsers using SRV DNS lookups to find servers. * https://news.ycombinator.com/item?id=17395600 https://news.ycombinator.com/item?id=17395600 SPF, of course, should be used everywhere so that we reach the point of complete balkanization and collapse, and people realize that we can (and in fact in some ways already have) switch wholesale to different systems, faster. (-: * http://jdebp.eu./FGA/smtp-spf-is-harmful.html http://jdebp.eu./FGA/smtp-spf-is-harmful.html * https://news.ycombinator.com/item?id=10405864 https://news.ycombinator.com/item?id=10405864
  - cm2187 8y ago
    Not that I think that SPF is the ultimate solution (it is merely a thin layer of lipstick on the pig) but I don't agree with many of the assertion of your "spf is harmful" link. - pre-delivery forwarding servers just need to be added to spf. If you use random third party smtp relays, then this is precisely what spf is trying to avoid. - the way internal servers implement aliases is their problem, there is not necessarily a need to go through an smtp relay (my mail server doesn't) - failover mail servers should check spf on incoming email and then have a trusted relationship with the primary server so that spf isn't enforced when the failover delivers to the primary (that's the way my mail server works) - spf uses DNS. So what? - ISP lock-in. If you control the domain/DNS entries, there is no lock in. If you don't, then you are already locked in anyway. - doesn't allow dynamic IPs. I'd argue that 1) it is a good thing 2) it's not really the case, you can specify a domain in spf, and this domain can be a dyndns style domain with a short lived TTL resolving to your current dynamic ip. And in theory you could also dynamically update your spf as your ip changes with a short TTL (like a dyndns-style entry). [edit] and actually what is going to kill you with a dynamic IP is not so much spf than the fact that the reverse dns of that IP won't resolve to your domain which is a big spam red flag for most smtp servers.

devereaux 8y ago

I fully agree. It will not achieve anything. FYI, "SMTP Require TLS" was running on port 465 many years ago. With many ISPs (and even some VPS) now blocking port 25, it could have been an opportunity to migrate naturally towards the "new" unencumbered port.

schoen 8y ago

Please see my reply downthread: https://news.ycombinator.com/item?id=17397816 https://news.ycombinator.com/item?id=17397816

ubernostrum 8y ago

The SMTP RFC says that mail servers MUST NOT The email RFCs require supporting a lot of things that are now horrendously outdated, and forbid doing a lot of things that should now be best practices. The RFCs should lose that battle.

axaxs 8y ago
See, at surface value I agree. But at a deeper level I don't. The problem is too many broken protocols exist via RFC only (dns, smtp, etc). Rather than violate that, or force it into something it's not, we should be writing newer, better protocols. The friction against this is huge, mainly by those who capped out at the previous RFCs, though. Email(well, smtp) itself is so outdated and broken, I can't believe it's still so widely used.
- JdeBP 8y ago
  IM2000 protocols have already been written. (-: * http://jdebp.eu./Proposals/IM2000/ http://jdebp.eu./Proposals/IM2000/ But of course you are already using a pull-style messaging system, that is right in front of you. * https://news.ycombinator.com/item?id=10405864 https://news.ycombinator.com/item?id=10405864
  - axaxs 8y ago
    Fair point, but I was thinking something like Signal, WhatsApp, or the like. So, I like to think of email as a bit dated, not only in security but in model. That said, the beauty of email is that you have a unique identifier that doesn't force the other party into your walled garden. If we could develop something akin to Signal, but that didn't require the second party to have to sign up explicitly for that service, I think that could finally start the process. Which, of course, would also require some level of initial adoption, probably the hard part.
- avaika 8y ago
  smtp might be broken, but it would be extremely hard to replace it to something incompatible, as it's a very core of the nowadays internet. Moreover it has the advantage no other popular communication service has: people somehow managed to agree on protocol standard so anyone is able to run own smtp server. In modern days of huge corporations a new popular standard like this seems impossible.

cm2187 8y ago

How did these committees think that optional, downgradable encryption was preferable to a standalone, encrypted only port (465)? Were they trying to save server ports, like if it was a precious resource? Any design decision I have seen regarding email since 2000 defies common sense. Like I heard most SMTP implementations do not validate certificates. What good is an unvalidated certificate? SPF is treated as indicative only or ignored. We are managing to replace http1.1 with http2, it will take time but it is on the way. I am not even aware that an actual SMTP2 draft protocol that would solve all these design flaws (unverified sender, unencrypted). And SMTP has a benefit http didn’t have. Most people access their emails through webmails, smartphones or enterprise outlook/exchange servers. For webmails and exchange only the server needs to be updated, and for smartphones, their short life ensures that older versions are pretty much all retired within 5 years. In addition, a handful of big players (google yahoo apple msft) have such a concentration of recipient accounts (retail users) that they can force a change on the market with the threat of your mail being classified as junk by them. So we could achieve a pretty quick transition.

JdeBP 8y ago
The same has been pointed out about Web browsers using SRV DNS lookups to find servers. * https://news.ycombinator.com/item?id=17395600 https://news.ycombinator.com/item?id=17395600 SPF, of course, should be used everywhere so that we reach the point of complete balkanization and collapse, and people realize that we can (and in fact in some ways already have) switch wholesale to different systems, faster. (-: * http://jdebp.eu./FGA/smtp-spf-is-harmful.html http://jdebp.eu./FGA/smtp-spf-is-harmful.html * https://news.ycombinator.com/item?id=10405864 https://news.ycombinator.com/item?id=10405864
- cm2187 8y ago
  Not that I think that SPF is the ultimate solution (it is merely a thin layer of lipstick on the pig) but I don't agree with many of the assertion of your "spf is harmful" link. - pre-delivery forwarding servers just need to be added to spf. If you use random third party smtp relays, then this is precisely what spf is trying to avoid. - the way internal servers implement aliases is their problem, there is not necessarily a need to go through an smtp relay (my mail server doesn't) - failover mail servers should check spf on incoming email and then have a trusted relationship with the primary server so that spf isn't enforced when the failover delivers to the primary (that's the way my mail server works) - spf uses DNS. So what? - ISP lock-in. If you control the domain/DNS entries, there is no lock in. If you don't, then you are already locked in anyway. - doesn't allow dynamic IPs. I'd argue that 1) it is a good thing 2) it's not really the case, you can specify a domain in spf, and this domain can be a dyndns style domain with a short lived TTL resolving to your current dynamic ip. And in theory you could also dynamically update your spf as your ip changes with a short TTL (like a dyndns-style entry). [edit] and actually what is going to kill you with a dynamic IP is not so much spf than the fact that the reverse dns of that IP won't resolve to your domain which is a big spam red flag for most smtp servers.