Slashdot Mirror
Gmail Becomes First Major Email Provider To Support MTA-STS and TLS Reporting (zdnet.com)
Google announced this week that Gmail has become the first major email provider to support two new security standards, namely MTA-STS and TLS Reporting. From a report: Both are extensions to the Simple Mail Transfer Protocol (SMTP), the protocol through which all emails are sent today. The purpose of MTA-STS and TLS Reporting is to help email providers establish cryptographically secure connections between each other, with the main goal of twarthing SMTP man-in-the-middle attacks. SMTP man-in-the-middle attacks are a major problem for today's email landscape, where rogue email server operators can intercept, read, and modify the contents of people's emails. The two new standards will prevent this by allowing legitimate email providers to create a secure channel for exchanging emails.
I want nothing to do with it!
Such as cornering the market for harvesting e-mail content to sell us more targeted ads.
"SMTP man-in-the-middle attacks are a major problem for today's email landscape, where rogue email server operators can intercept, read, and modify the contents of people's emails. "
Google/Alphabet does the first two then pinky-swears to not do the third.
Come on editors.
While this is an improvement, Google's motives are suspect. I suggest instead an end-to-end encryption extension to SMTP. We could call it FU-GOOGLE.
My servers have been negotiating TLS connections for years. What's all this about?
No matter how secure the pipelines, it still ends up at Google? If you are worried about security, you should not be using their data-harvesting services in the first place!
They can support Support MTA-STS and TLS Reporting all they want. Inbox was still better.
Is that worth two farthings?
I keep thinking, we keep creating application and service level encryption to protect data transmission - but why not at the stack level, or one level deeper - the transport or network layer? Each physical network device should create a public/private key encrypted connection per remote host they are connecting to, and store that key in an on-chip storage that gets orphaned or erased when the connection closes.
It seems to me that if we added a deeper level of strong encryption to the physical devices then application level encryption becomes a 2nd level of protection as redundancy. I'm sure people much smarter than me have thought of this, but why has it not become standard?
Rather than relying on "trusted" CA's, many in countries known for hacking/cracking, we use our own full featured CA and support validation of our email certificates using DANE in our authoritative DNS.
Simply insist on STARTTLS and promote an approach that's close to current technology.
Why would I want to secure only segments of the information transfer when this means there are still plenty of points where adversaries can tamper with my email? The better solution has been around for decades already, it's called end-to-end encryption, and implemented for example by GPG.
Normally, when I consider "protecting my information from eavesdropping", the eavesdroppers I'm concerned about are Google (or Facebook, or Amazon, or similar companies.)
Your ad here. Ask me how!
It's another attempt by Google to confuse the market that they value your privacy, by pushing encryption of in-transit private user data to their very not-private email servers.
Previously they forced Https on sites or downgraded them in search results for jon-compliance.
Don't get me wrong. You can't trust the SOBs running the wires anymore, so transport encryption isn't a bad idea. I have had opportunistic SMTP-TLS (and DMARC reporting) on my mail servers for years, and notably, gmail was one of the first doing it consistently.
Google's Orwellian marketing is depressingly brilliant at their branding work here.
I too wish to twarth attacks. If you ask nicely, I might even try to thwart them.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Yep, I didn't realize it was a dupe either, but I'll repost the same comment:
As usual, the technology remains morally neutral, but another technical bandage is NOT a real solution. Just another flavor of "Live and let spam", and the REAL objective of such weak-@ssed technical approaches is to deny liability for any harms done.
The specific aspect of spam that bugs me most is the time wasted. If the google was liable for all the time wasted by their support of spam, I think they'd be bankrupt, even at minimum wage rates. Other people might be more annoyed by the abuse of corporate reputations. Or maybe you're annoyed by the abuse of personal information? Or the entry-level-crime argument, especially for phishing and identity theft?
Anyway, I always want to see the solutions. So what am I doing on Slashdot these years?
My favored solution approach is to go after the spammers' business models. There's even an obvious proof of concept. Where is all your pump-and-dump stock-scam spam? Gone, gone, gone. Because they went after those spammers' business model--though only after several research papers proved that the scam worked so well it was like printing money.
Why aren't such approaches being adopted? My theory is because they'd have to work with us. To really fight the spammers effectively they'd need to collaborate with the potential victims. One part of it is that we are the only ones who know our side of the targeting. It doesn't matter how good the spam looks if I actually know that I've never done business with that bank, eh? But the bigger part is that they don't want to reveal how much of our personal information they are already holding. They don't have to ask me for such categories of information because they probably have all the details already. Probably even the account numbers.
Freedom = (Meaningful - Coerced) Choice != (Speech | Beer^2), and sad sock puppets' bad mods avail them naught.