This sounds great but Google has been making it harder and harder to run your own mail server even for personal use. I think they would be happy of email servers were only run by a few large companies. They make it sound like they are doing the right thing but really they are bully the industry to do it their way. So many people have Gmail accounts that you can't run an email server that cannot send email to Google.
I've run my own email server for about 15 years. Every now and then I have to drop everything and implement some new technology that Gmail demands I have. Granted SPF, DMARC and TLS are all great technologies but I take issue with Google making the decision that everyone is going to switch, now and with out sufficient warning.
I'm in the same boat as you - running a personal/friends/family mail toaster for 16 years now. But I disagree that Google have made the administration harder. Internet mail servers don't live in isolation, and context has always been changing. I have no issue with adapting configuration as expectations change, so Gmail's evolution has never inhibited my ability to exchange email with the world. This move is no different. Really, I feel that the elephant has been tremendously careful not to tread on the mice.
I don't believe this particular change materially improves security, since it isn't representing an end-to-end behaviour, but if it raises awareness and challenges mass surveillance then so much the better.
Personally I would like them to advocate for other necessary infrastructure advances and include, for non-IPv6-capable MTAs, an icon of a lurching monster that refuses to die.
The article is pretty clear that gmail users can keep emailing others who don't support TLS or authentication; they will just now see an additional icon informing them of that condition. Nobody is being demanded to switch anything.
Now I can just get a free cert and turn on TLS. What's the problem, exactly?
Most people are not capable of running their own mail server. The convenience of services like Google, plus the risk of turning your mail box into a spam machine, vastly outweighs the downsides for most people.
And as to "sufficient warning," sure, I can see that it would be nice to have given people like you more lead time. But then again, "GMail has always supported encryption in transit using TLS," and if you care about running your own email server, it feels to me like the writing has been on the wall for that one for a long time.
I disagree - I run a personal mail server and dkim+spf just took a little bit of research to set up, so I'm very glad this brought them to my attention because I want to do what I can to make my emails trustworthy.
If there are any potential downsides to these things I'm interested to hear them, but it seems like they're generally agreed good practices, and hosting your own mail means you're signing up for some ongoing learning and maintenance anyway.
Maybe I'm in an odd position, but is email really such a big communication tool? I mean sure in business world, but for that companies have their own email servers anyway. I only receive email from 2FA-things and order confirmations/paypal recipes. I hardly ever actually send anything from Gmail or receive anything from actual people. All my communication with actual people is either through apps like Signal or WhatsApp or through IM like IRC
Main complain to Google or other big company. Stop putting email in spam that doesn't have reverse DNS set. Why should one IP be tight to one email domain?
Well, it would be much worse if they refused to implement those enhancements, or tried to force proprietary or gmail-specific alternatives.
They pretty much had to do something to improve e-mail's abysmal confidentiality and authenticity, and at least they used open technologies which can be configured on a Debian VPS in a couple of hours using a HOWTO.
I think as HNers, we're focusing too heavily on niche cases (like running your own email server). But, for general public who is still sharing their own (and more importantly, their clients') SSNs, passwords, and other very sensitive information on email, this may be the trigger that educates / trains them to be more careful. I am definitely looking at this as a positive.
There's a lot of things that I question about Google, but forcing their Gmail customers to adopt more secure practices is worthy of praise. They are the biggest free email provider in the world, and they are owning up to a responsibility to ensure their users can work safely.
Those running their own email servers have a similiar responsibility to their own users, even if it's only themselves. You had time to set up the server in the first place, so you have time to make it work with TLS. Now that Let's Encrypt is here there's no excuse to be running an insecure email (or web) server.
> Not all affected email will necessarily be dangerous.
To me, it sounds like they're saying that most of the "affected email" WILL be dangerous -- just not ALL of it -- and that's highly misleading, of course.
Overall, though, I think this will be a good thing if it pushes more organizations ("mail senders") to implement opportunistic encryption for incoming mail and SPF/DKIM signing for outgoing mail.
That seems to be what they're referring to; that is, sending to an MX host that doesn't support opportunistic encryption) and/or receiving mail that doesn't have a valid DKIM signature. Did anyone else understand this differently?
This will be popcorn time for those using Gmail for business.
I have a plugin in Thunderbird that shows the DKIM status of incoming email as gray/red/green, meaning no DKIM/DKIM invalid/DKIM valid. Most of the email I get from business accounts (usually on Exchange), including those from the company I work at, have no DKIM. (Yes, I've complained to the ITsec dept. They don't even have SPF set up...) Of the rest, surprisingly many have invalid DKIM sigs.
>If you receive a message that can’t be authenticated, you’ll see a question mark in place of the sender’s profile photo, corporate logo, or avatar.
This makes it sound like I (the sender) can set the image displayed if I am using DKIM. Is that the case? Or is it only if I have DKIM and have a Google account with that email?
Gmail uses an associated Google+ profile for authenticated emails, so you need both for it to work going forward, I presume. To get started, check https://www.google.com/business/
There really should be some kind of standard or mail header though. :) Come to think of it, services could support a vcard mime-type attachment, perhaps? Except that likely wouldn't support URLs to profile photos... Maybe we've identified a missing feature of DKIM? ;-)
Interesting. I'm wondering if they also warn Gmail users if a mailserver has TLS enabled with a self-signed certificate. Because i think many mailservers actually support TLS but do ignore certificate verification, because of the self-signed certificates.
Unfortunately, this is the sort of a change that's a red herring for any actual improvements to email security.
The use of unencrypted or encrypted link to the receiving email provider's MX server doesn't change all that much in terms of who can read the email: it's still sitting in plaintext on the recipient's server (as well as the sender's server), and the group of actors who can sniff traffic on the backbone like that is probably just as easily able to get it from the servers.
The authentication feature is even worse. The problem of spam and phishing isn't that email claims to be from [email protected], it's that email claims to be from "Big Bank" <[email protected]>. It's been noted before that spammers tend to be the most aggressive at uptaking new "anti-spam" technologies like SPF and DKIM, and this sort of validation feature seems like a prime vehicle for exploitation by spammers.
You're arguing that we shouldn't do anything, instead of taking a step in the right direction. Email is an old ecosystem, so it's not possible to make big improvements all at once.
There's a lot of supposition in your post and no evidence in favor. First of all what makes you think Gmail stores user data in plain text at rest? Secondly think about your definition of "backbone" networks. Google's own network is extremely large in scope, and generally user traffic lands in Google's network at a point very close to the user. For example if a user in Japan sends mail to Google, that connection will be terminated in Japan, and backhauled across Google's network to wherever the actual servers are located. Google intentionally shrinks the scope of network surveillance by minimizing the network distance between the user and Google's frontends.
> The use of unencrypted or encrypted link to the receiving email provider's MX server doesn't change all that much in terms of who can read the email: it's still sitting in plaintext on the recipient's server (as well as the sender's server), and the group of actors who can sniff traffic on the backbone like that is probably just as easily able to get it from the servers.
That's not at all obvious to me. And this sort of backbone sniffing is exactly what we've seen state actors do. What possible downside could rewarding link integrity have on the story for user privacy? A false sense of security? Quite the opposite: that's what we already got in spades.
Good initiative. Question is; what does the TLS icon indicate; is it just opportunistic TLS, or do they do any verification? What, if so? Some private consortium where only members can get a "green lock"?
I wholly agree regarding email hosted in the United States, especially for any emails stored over 180 days on servers you don't own (see Electronic Communications Privacy Act of 1986).
meh. This doesn't seem very interesting.
What would be really interesting is gmail support for public key encryption. They're perfectly positioned to roll out a user-friendly key management system.
Webmail struggles to offer security reassurances when utilising public key encryption. For example if Google allowed you to upload your private key and email would be transparently decrypted, that would be a great user experience, but now you have no way of knowing if the NSA/GCHQ/etc forced Google to give them your private key.
If you didn't upload your private key to Google now you need your browser to decrypt your message in-line but preventing the website with the encrypted version from stealing the resulting decrypted version from the secure container. So that requires every browser to add these secure containers, for content to be marked for decryption, and for key storage.
If you aren't worried about usability then you could just write a Word document, encrypt it and attach it to an unencrypted email. No browser support, or website support needed.
For anyone wishing to run their own mail server, check out Mail-in-a-Box[0]. It's relatively easy to set up, comes with a nice Web GUI and they recently added support for automatic provisioning of TLS certificates with Let's Encrypt.
I'll tell you what I want: I want Google to help identify non-DKIM-compliant forwarders. As the operator of (yes, I know) a vanity e-mail domain with DKIM, SPF, and DMARC records, I have no problem sending mail to gmail directly; in fact, my outgoing mail uses postmark, so I'm not even directly responsible for my sending reputation.
BUT! It drives me crazy that many of my recipients get e-mail at hosts (schools, mostly) that forward the e-mail
with differences (encoding changes, subject changes, etc.) that invalidate the DKIM signature. Since they're forwards, the SPF check is going to fail, too, so the end result is that google shoves it into a spam folder.
I claim that google definitely has the data to be able to identify these bad forwarders--heck, even mail sent from gmail to these hosts will presumably fail DKIM checks on the way back into google--and I'd love to see them contact these domains, or even publish a list of known bad forwarders, so that I can push them to make changes.
I'm glad that companies are starting to display warnings about insecurity. It used to be that the insecurity was only advertised if something that was supposed to be secure was broken. However not having any security in the first place is often worse. I would like to see this trend continue and start warning everyone about systems that aren't secure.
I think that's the point---they should assume the worst.
It's part of a general trend of moving the needle from "Internet services are insecure and if you really want to send something secure, you should be sure your channel is encrypted" to "These channels should always be secure; if they're not, here's a big red flag to warn you that they are not."
See also the process of bypassing the "This site is insecure" alarm interstitials in Chrome and Firefox these days for sites with bad secure TLS credentials. The frog has been boiling from "We warn the user with a tiny icon they'll probably ignore" to "Users have to know secret words or convoluted config flows to bypass this inescapable error panel."
I wish someone made a better (non-SMTP) messaging standard which is secure, efficient, easier to understand/implement and without a clutter of all legacy stuff (and hopefully with a decent reference implementation!). Spams would still remain, but at least that would free us from worrying about the transportation layer security. (But then we might need to reinvent something like DNS on the way, so maybe that's why that no one is trying this.)
[+] [-] jcoffland|10 years ago|reply
I've run my own email server for about 15 years. Every now and then I have to drop everything and implement some new technology that Gmail demands I have. Granted SPF, DMARC and TLS are all great technologies but I take issue with Google making the decision that everyone is going to switch, now and with out sufficient warning.
[+] [-] inopinatus|10 years ago|reply
I don't believe this particular change materially improves security, since it isn't representing an end-to-end behaviour, but if it raises awareness and challenges mass surveillance then so much the better.
Personally I would like them to advocate for other necessary infrastructure advances and include, for non-IPv6-capable MTAs, an icon of a lurching monster that refuses to die.
[+] [-] tantalor|10 years ago|reply
> everyone is going to switch, now
The article is pretty clear that gmail users can keep emailing others who don't support TLS or authentication; they will just now see an additional icon informing them of that condition. Nobody is being demanded to switch anything.
disclaimer: works for Google
[+] [-] Navarr|10 years ago|reply
Without SPF/DKIM you can't be authenticated. Google is showing the user that they cannot verify the sender.
Without TLS email is sent in the clear. Google is showing the user that sensitive information will be visible when sent over the network.
You can run your server fine without this, but users will be warned that you're not following best practices.
It is not Gmail's fault that you're late to best practices.
[+] [-] emergentcypher|10 years ago|reply
Most people are not capable of running their own mail server. The convenience of services like Google, plus the risk of turning your mail box into a spam machine, vastly outweighs the downsides for most people.
[+] [-] wdewind|10 years ago|reply
[+] [-] VikingCoder|10 years ago|reply
Measurably.
And as to "sufficient warning," sure, I can see that it would be nice to have given people like you more lead time. But then again, "GMail has always supported encryption in transit using TLS," and if you care about running your own email server, it feels to me like the writing has been on the wall for that one for a long time.
[+] [-] jms703|10 years ago|reply
insecure mail server
[+] [-] collinmanderson|10 years ago|reply
The DKIM authentication just requires a self-signed certificate. It doesn't need to be signed by a CA, I believe.
[+] [-] jankins|10 years ago|reply
If there are any potential downsides to these things I'm interested to hear them, but it seems like they're generally agreed good practices, and hosting your own mail means you're signing up for some ongoing learning and maintenance anyway.
[+] [-] 746F7475|10 years ago|reply
[+] [-] treenyc|10 years ago|reply
[+] [-] rphlx|10 years ago|reply
They pretty much had to do something to improve e-mail's abysmal confidentiality and authenticity, and at least they used open technologies which can be configured on a Debian VPS in a couple of hours using a HOWTO.
[+] [-] emergentcypher|10 years ago|reply
[deleted]
[+] [-] sinatra|10 years ago|reply
[+] [-] jacquesm|10 years ago|reply
[+] [-] Animats|10 years ago|reply
[+] [-] vsviridov|10 years ago|reply
Used this service to make sure my setup is correct: http://www.checktls.com/index.html
Also, thunderbird apparently does not like Alternate Subject Name for smtp, but with Let's encrypt I can just issue a mail server-specific key.
[+] [-] dcw303|10 years ago|reply
Those running their own email servers have a similiar responsibility to their own users, even if it's only themselves. You had time to set up the server in the first place, so you have time to make it work with TLS. Now that Let's Encrypt is here there's no excuse to be running an insecure email (or web) server.
[+] [-] jlgaddis|10 years ago|reply
> Not all affected email will necessarily be dangerous.
To me, it sounds like they're saying that most of the "affected email" WILL be dangerous -- just not ALL of it -- and that's highly misleading, of course.
Overall, though, I think this will be a good thing if it pushes more organizations ("mail senders") to implement opportunistic encryption for incoming mail and SPF/DKIM signing for outgoing mail.
That seems to be what they're referring to; that is, sending to an MX host that doesn't support opportunistic encryption) and/or receiving mail that doesn't have a valid DKIM signature. Did anyone else understand this differently?
[+] [-] semi-extrinsic|10 years ago|reply
I have a plugin in Thunderbird that shows the DKIM status of incoming email as gray/red/green, meaning no DKIM/DKIM invalid/DKIM valid. Most of the email I get from business accounts (usually on Exchange), including those from the company I work at, have no DKIM. (Yes, I've complained to the ITsec dept. They don't even have SPF set up...) Of the rest, surprisingly many have invalid DKIM sigs.
[+] [-] finnn|10 years ago|reply
This makes it sound like I (the sender) can set the image displayed if I am using DKIM. Is that the case? Or is it only if I have DKIM and have a Google account with that email?
[+] [-] lstamour|10 years ago|reply
Outlook uses Facebook and Twitter, if you have these contacts integrated. Yahoo does this too: http://techcrunch.com/2015/03/04/smart-contact-cards-arrive-...
There really should be some kind of standard or mail header though. :) Come to think of it, services could support a vcard mime-type attachment, perhaps? Except that likely wouldn't support URLs to profile photos... Maybe we've identified a missing feature of DKIM? ;-)
[+] [-] tomputer|10 years ago|reply
[+] [-] jcranmer|10 years ago|reply
The use of unencrypted or encrypted link to the receiving email provider's MX server doesn't change all that much in terms of who can read the email: it's still sitting in plaintext on the recipient's server (as well as the sender's server), and the group of actors who can sniff traffic on the backbone like that is probably just as easily able to get it from the servers.
The authentication feature is even worse. The problem of spam and phishing isn't that email claims to be from [email protected], it's that email claims to be from "Big Bank" <[email protected]>. It's been noted before that spammers tend to be the most aggressive at uptaking new "anti-spam" technologies like SPF and DKIM, and this sort of validation feature seems like a prime vehicle for exploitation by spammers.
[+] [-] skybrian|10 years ago|reply
[+] [-] thrownaway2424|10 years ago|reply
[+] [-] KirinDave|10 years ago|reply
That's not at all obvious to me. And this sort of backbone sniffing is exactly what we've seen state actors do. What possible downside could rewarding link integrity have on the story for user privacy? A false sense of security? Quite the opposite: that's what we already got in spades.
[+] [-] Bino|10 years ago|reply
What's the next step? Do they have DANE https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Na... in mind, or some other initiative to get verified encryption such as "TES" https://openbit.eu/projekte/trusted-internet-services/
[+] [-] MicroBerto|10 years ago|reply
This is the best way of approaching that technology.
[+] [-] Esau|10 years ago|reply
[+] [-] fixermark|10 years ago|reply
Securing email end-to-end is a solid step in the right direction towards making it work better for end-users.
[+] [-] headstorm|10 years ago|reply
[+] [-] waffle_ss|10 years ago|reply
[+] [-] jacobr1|10 years ago|reply
[+] [-] asquabventured|10 years ago|reply
#chillingeffect
Welcome to 2016
[+] [-] ecthiender|10 years ago|reply
Fastmail (https://www.fastmail.com/)
Tutanota (https://tutanota.com/)
Riseup (https://help.riseup.net/)
[+] [-] Diederich|10 years ago|reply
[+] [-] Navarr|10 years ago|reply
These are good-for-the-user policies.
[+] [-] more_corn|10 years ago|reply
[+] [-] Someone1234|10 years ago|reply
If you didn't upload your private key to Google now you need your browser to decrypt your message in-line but preventing the website with the encrypted version from stealing the resulting decrypted version from the secure container. So that requires every browser to add these secure containers, for content to be marked for decryption, and for key storage.
If you aren't worried about usability then you could just write a Word document, encrypt it and attach it to an unencrypted email. No browser support, or website support needed.
[+] [-] andygambles|10 years ago|reply
[+] [-] michaelmior|10 years ago|reply
[0] https://mailinabox.email/
[+] [-] jbclements|10 years ago|reply
BUT! It drives me crazy that many of my recipients get e-mail at hosts (schools, mostly) that forward the e-mail with differences (encoding changes, subject changes, etc.) that invalidate the DKIM signature. Since they're forwards, the SPF check is going to fail, too, so the end result is that google shoves it into a spam folder.
I claim that google definitely has the data to be able to identify these bad forwarders--heck, even mail sent from gmail to these hosts will presumably fail DKIM checks on the way back into google--and I'd love to see them contact these domains, or even publish a list of known bad forwarders, so that I can push them to make changes.
[+] [-] kevincox|10 years ago|reply
[+] [-] ck2|10 years ago|reply
[+] [-] fixermark|10 years ago|reply
It's part of a general trend of moving the needle from "Internet services are insecure and if you really want to send something secure, you should be sure your channel is encrypted" to "These channels should always be secure; if they're not, here's a big red flag to warn you that they are not."
See also the process of bypassing the "This site is insecure" alarm interstitials in Chrome and Firefox these days for sites with bad secure TLS credentials. The frog has been boiling from "We warn the user with a tiny icon they'll probably ignore" to "Users have to know secret words or convoluted config flows to bypass this inescapable error panel."
[+] [-] mayerzahid|10 years ago|reply
Create your free DMARC record here: https://app.agari.com/dmarc/record_creator
Here is a webinar with Steve Jones, Executive Director of DMARC.org, John Rae-Grant of Google and Mike Jones, Agari Director of Product Management talking about email authentication. https://www.agari.com/project/webinar-the-authenticated-emai...
[+] [-] euske|10 years ago|reply
[+] [-] Nux|10 years ago|reply