Re:RFC 8314: Use of Transport Layer Security for Email Submi...
by 3pt14159 on Wednesday January 31, 2018 @08:11PM
(#16278999)
This type of thinking is how we get ants.
It is trivial to set up a mail server with TLS and if you don't have fucking TLS bounce it through a protocol upgrade server. If you understood the type of secrets that are getting trivially intercepted you'd realize that a couple hard days for a couple of lazy sys admins is a tiny price to pay for the drastic increase in security.
People are literally getting killed because we're so fucking lazy. Even three letter agencies are sending mail without TLS, this is madness.
Re:RFC 8314: Use of Transport Layer Security for Email Submi...
by cortesoft on Thursday February 01, 2018 @12:40AM
(#16279836)
What mission critical legacy hardware/firmware doesn't support TLS and is sending email to gmail?
Anyone running that mission critical hardware is free to keep using insecure email, no one is going to stop that. If they really need to send email from that old hardware to gmail, they can set up their own relay that accepts non-tls connections but relays using TLS.
Re:RFC 8314: Use of Transport Layer Security for Email Submi...
by secabeen on Thursday February 01, 2018 @01:24AM
(#16279946)
Nearly every printer/copier with a scan-to-email feature in a small-to-medium size business that has moved their all their servers and email into the cloud.
Re:RFC 8314: Use of Transport Layer Security for Email Submi...
by randomString1 on Wednesday January 31, 2018 @11:20PM
(#16279622)
Even if they define a 5 to 10 years warning before "deprecating" it is better than finding ourselves in the same hole the same amount of years from now.
For message relaying, your proposal might indeed work. The vast majority of inter-domain mail traffic goes through a very small number of providers. No mail provider can afford to not be able to exchange mail with gmail, or office365, or ...