Gmail Will Warn If Message Is Not Authenticated/Encrypted
gmailblog.blogspot.com
gmailblog.blogspot.com
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 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.
Really that's bothers me greatly. Email is the example of a successful open protocol and by all means you should try and do it yourself. The less we are reliant on these giant companies the better and to abdicate email to google just because they've achieved critical mass is to wipe 25 years of internet history under the carpet.
Decentralization is good, not bad.
If installing and operating a compliant email server is too hard then we should make that easier, not push to get everybody to switch over to some corporation.
For comparison: the sidelining of XMPP by corporate interests was awfully disappointing; the centralisation of social networking feeds is downright heartbreaking. But none of that should put us off trying and trying again. Everyone with an interest in how the Internet protocol stack works in context should try running their own mail service, it's a fantastic and low-cost way to gain insight.
I'm frightened as well that google is taking over email. As long as people rely on web based email, there's no hope for actually encrypting email. TLS is nice, but really, it doesn't mean much. Your email is stored plain text on Google's servers anyways.
> 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
What are the SSL certificate authority requirements?
We do not accept self-signed certificates. For a certificate to be valid it needs to chain up to a valid CA, like one in the Mozilla CA list.
As a recipient of all kinds of mail, I'm okay with that. I'd rather not see that unencrypted email than have it QUANTUM INSERT'd or whatever the Chinese equivalent is.
How many months is a "few"?
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.
Fixed that for you.
Well, except they are. Before, yes, they were just best practices. It was great if you had them but by no means required and didn't really impact your experience much if at all. With this switch, though, they became requirements to getting a "normal" experience in Gmail. Even having a warning is a degraded experience at this point.
If I ran a restaurant that provided extra services, that doesn't stop anyone else from opening a restaurant and provide similar levels of service.
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.
> Most people are not capable of running their own mail server.
I think that is a big part of the problem. It should be relatively straightforward for someone who isn't a full-time email server administrator to setup a mail server correctly, but it's not. At least, it wasn't easy last time I tried it with Postfix and (iirc) Courier on Ubuntu. All the cryptography options are disabled by default and you have to spend a lot of time figuring out which ones should be turned on, where to stick the certificate files and how they should be formatted, how to get Courier and Postfix to talk to each other, etc...
Maybe there's an easy solution (besides "pay someone a monthly fee to manage this all for me") that I'm oblivious to, but it seemed like I was on a well-travelled path and it was a lot harder than it should have been.
http://arstechnica.com/information-technology/2014/02/how-to...
It shows how to set up SPF, DKIM, TLS, anti-spam filtering, Sieve, certificate-based authentication (I still haven't figured out how to do this with an iPhone), and so on. The only bolt-on it references but doesn't explore and I actually used is the Z-Push package to implement ActiveSync.
Do you encrypt the email on disk, or are they stored in plain text?
That, I think, is why the distribution managers don't make the default configurations a little more friendly/sane; most users aren't interested in installing a MTA to do anything but local delivery or smarthosting, and the people who are, are probably going to tweak the configs to death anyway, so it's not worth spending the time making it run well and securely straight out of the box.
It wouldn't be too hard to build a "mailserver in a box" with (say) Debian + Postfix + LetsEncrypt + BIND that you could stand up in an hour and be reasonably secure (and I'd be kinda surprised if that doesn't exist in some form already), but I don't know how many people would want it who aren't running mailservers already, and have the capability of doing so.
As with so many things in AWS, it's left up to the customer to inform AWS that a) you're running a mail server, b) what the purpose/use case is and c) request they configure the reverse lookup associated with the elastic IP you've allocated.
Source: I've been running public facing SMTP servers in EC2 for years with no issues.
https://aws.amazon.com/ses/faqs/
Still, unless you're running a server for a lot of people and you have tons of free time, you'll discover that it's more expensive than paying any of a bunch of people to take care of email for you.
Source: I work at FastMail
I'm having high hopes for Ubuntu 16.04 having a more recent version on board. Then I will try to switch from postfix again. Because as you've said, it's really straightforward to set up :)
Certs weren't free for business use until let's encrypt.
The pervasiveness of self-signed certificates for SMTP servers means that rejecting them would drop large amounts of email. STARTTLS is basically useful for thwarting passive collection of network traffic.
And if I can point your MX records there, via hijack or any other means, then I have a valid SSL certificate for receiving your email.
DKIM (which does not use a CA-issued certificate, it uses a public key published in DNS) is the technology that's intended to authenticate the email sender. It still wouldn't stop phishing attacks where the purported email sender is something like "admin@facebook-account-verification-2016.net" though, and I don't know that there really is a good technical solution to that sort of thing.
Except everything you send and receive with your Gmail account is read by them and whatever government agencies anyway... So what's the point?
As a publicly traded company, it optimizes for GOOG. I have nothing against google, but I do think there is not enough skepticism our fear about them eating the whole stack.
* Receive gmail link from friend. * Use Chrome Browser as gateway to internet. * Use DNS to resolve that URL. * Site built on Angular and has new SPDY tags. * Libraries and Fonts served from CDN.
see something unclear at the url.
* use google search to find that link * google analytics beacons on both websites report your traffic.
I am concerned about the temptation for google to get up to something naughty. Luckily, as we now, it is an undisputed fact that our data is 100% safe with google and there are no organizations trying to actively attack their network or intercede. We also know, that compromising an individual (either an employee or a customer of google) is 100% impossible, never has happened, and never conceivably could happen. So it isn't a big deal.
So, is the issue you can't run a mailserver? Maybe. Maybe not.
You can't crawl many valuable sites now, unless you are google bot or a big vendor.
2 (3 if we count microsoft) companies can ban you from competing on mobile.
etc.
The slight losses in some areas to optimize for what google wants are small. In aggregate, they are wildly irresponsible for us to accept and we shoudlnt.
False. The voting stock are not traded, so the founders still have irrevocable rights to do whatever they please.
I meant, and you correctly pointed out was not clear or a particularly good way to verbalize, that google like most companies does what is best for itself. In googles case this is a combination of maximizing shareholder value and the vision various thoughtleaders in the company have.
I do not believe google is evil or bad.
I used to believe this.
I now believe that google is doing a lot of great things. However by achieving horizontal success in almost every area of such a powerful concept, it effects how the landscape develops and does cause many issues.
Even if we accept google is mostly good, and I mostly do, it is concerning. I hope that their voluntary meta structure will allow them to distribute fault tolerance and limit power consolidation.
As far as "I take issue with Google making the decision that everyone is going to switch, now and with out sufficient warning." it would be nice to get some notice on these changes no doubt but email is shit. It just is but we are stuck with it and at least google is attempting to drag it forward even if in doing so they leave some outdated servers/services behind. I'll take more secure of infinitely backwards compatible any day.
So email is shitty because providers fuck with it at the mailserver level (i think this is the case, and have heard that about providers) as it doesn't seem to be a problem at the view level.
So this is sort of the issue. We couldn't get consensus on this early on, so no one was able to force standardization, now only a few players have the ability to define standards but they all own large scale messaging channels outside of email.
edit: meant to say that browsers obviously view html and css3 is pretty good as well. We could probably standardize this enough to allow people to write emails in this format and embed imagery. We would not allow JS for obvious reasons, but sending cool emails would be fun and we could also add new features. I mean, the web has developed somewhat shittily, but adding a few new features outside of like the 16 original tags would be cool. Not sure what percentage of tags and attributes actually work, but then again, no one is...
I don't think it needs to be changed, really. It will stay this useful forever, probably.
What does that mean? A mail server can be a small perl script running on an embedded computer, or it can be a hundred front-end SMTP servers using a database as a back end datastore, there's no real infrastructure limit other than being able to make and receive connections on TCP port 25.
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.
insecure mail server
I understand gmail's problem, and I don't have a better solution, but it's not just about insecure mail servers.
The DKIM authentication just requires a self-signed certificate. It doesn't need to be signed by a CA, I believe.
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.
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.
Like why would I need to give my SSN to register for an account to take the GRE exam? And why would anyone ever make SSN an optional field? If its not required why would you ever ask for it?
One reason might be that some states have laws on the books that prohibit requiring people to give you their SSN (unless you are actually required to collect it by some other law, of course).
> If its not required why would you ever ask for it?
All the answers to this are depressing. :(
If you're using Gmail or sending to a gmail address[1], you know what you are in for, and if you don't you should at least know that anything you send to someone else is no longer in your control and you have very little control over who sees it.
1: Google Apps for business accounts are not scanned for ads.
If you want free email, expect to pay in some other way. There's no such thing as a free lunch.
No, I'm serious about this. I wasn't trying to be flippant. If you care enough about the integrity of your email content and it not being used to further a company's profit, the only way to be sure of that, to the extent that you can (which may not be much), is to run your own mail server. If that seems like it's way too much trouble, I think a you should take a close look at your motives for wanting a gmail alternative. Is it about the integrity of your email, or sticking it to Google? If it's avoiding Google because they specifically cause you concern, that's fine, and there likely plenty of choices, but I'm not sure what they are (as I said, I just use Gmail because I don't care).
> By your logic even a private mail server isn't enough, you'd have to use PGP.
Well, by my logic you have to do enough to make yourself comfortable. Depending on your reasons for avoiding some other companies that will be different things.
> If you don't have any recommendations just say so.
I don't have any recommendations for Gmail if you consider a good UI, responsively web based, and free as major components of that. If you are willing to give up one or more of those, there are options. The local ISP I mentioned is Sonic.net. By all accounts (including mine, I've worked there multiple times in the past), a great company, and with great EFF ratings. An email account there is not free though.
Do you have any source for that claim, or is it just pure libel?
Seriously: this is calling out Google in a way that's comical since it's equally applicable to your own computer.
Single point of failure.
Government entities have to go through physical work to seize multiple mail servers distributed geographically. This keeps the cost of fishing expeditions high enough that they won't just do it by default.
With everything at Gmail, Yahoo, and Microsoft, you only need to serve 3 entities, who already are known to roll over.
However, far more concerning to the HN crowd should be this fact: Do you want the companies most likely to buy you out for a large value to be the ones holding all of your internal emails?
At this point, Google probably knows more about the quality of business than the businesses do. It would be an interesting question as to whether Google could be considered a corporate insider for a vast number of companies.
Okay?
> Government entities have to go through physical work to seize multiple mail servers distributed geographically. This keeps the cost of fishing expeditions high enough that they won't just do it by default.
Except they seem pretty seize-happy and the only thing protecting your house is the say-so of a judge.
> With everything at Gmail, Yahoo, and Microsoft, you only need to serve 3 entities, who already are known to roll over.
That seems quite unfair, as at least 2 have been very public about their expenditures to try and make such attacks impossible in the future, and have vocally fought subpoenas.
> Do you want the companies most likely to buy you out for a large value to be the ones holding all of your internal emails?
Yes. The lawsuit should I discover it would probably make me richer and more famous than all the buyout events I've experienced.
You're being obtuse. Even if every judge rolls over, if you have to seize multiple email servers in multiple jurisdictions, the paperwork represents expense and time that law enforcement simply will not do unless they have a really strong reason. "People are lazy" is the universal constant. We fear computerization of things precisely because computers aren't lazy.
> That seems quite unfair, as at least 2 have been very public about their expenditures to try and make such attacks impossible in the future, and have vocally fought subpoenas.
That's what they say publicly. However, if they roll over for governments like China, they're going to roll over for the US who can genuinely affect their revenue stream.
> The lawsuit should I discover it would probably make me richer and more famous than all the buyout events I've experienced.
Your naivete is touching. Google wouldn't do anything actionable. They scan your email store and know not to invest. You'll never prove anything for a passive non-action like this.
Even for positive action failures, it's very difficult to prove. This is the whole point of "parallel construction". You dragnet to find something incriminating, and then build the legal path to what you now know to search for.
Your trivial additional inconvenience running what sounds like a non-trivial geographically dispersed non-cloud-service email system warrants not calling out services with poor mail transit security. So millions of customers improved security vs you figuring out how to use LetsEncrypt. Because Google subsidizes the free service with ads.
I do not follow this logic, but what's more:
> Google wouldn't do anything actionable. They scan your email store and know not to invest. You'll never prove anything for a passive non-action like this."
Yeah well having sold a few companies to a few mega-nationals, we try to be honest and deserve the acquisition, as opposed to trying to fleece people. Lame-duck acquisitions shit on employees for investor gain, often for investment clawback and exit.
But also, if you are a paying edu or org customer, they stop scanning for and serving ads.
So forgive me if I don't feel a ton of empathy towards your strong desire to be dishonest in a hypothetical google acquisition where they hypothetically do this.
It won't count for anything if the emails your server is sending/receiving are not encrypted, which exactly is what Google is advocating. I don't understand GP's smug rejoinder, as if encrypting emails in transit is a bad thing.
You're one judge's pen-stroke away from having personal property seized and then it's just a matter of how real your machine's physical security measures are.
Quite true. If you, personally, are a target of the NSA, you are totally fucked. We know that they will make up evidence if they cannot find some.
However, we put locks on our doors even though most of them can be picked very easily. Why?
Security best practice is "defense in depth". You defend at each level to make it more expensive for an attacker. The goal is to make attacks against your stuff more expensive.
If you make the government have to dispatch someone physically, there is a vast amount more friction. There was an inspector from Scotland Yard who once commented that "If your drives are encrypted such that it takes us more than 40 hours of work, your drives are not going to convict you. We will spend our time on gathering other evidence." Physically seizing a server is annoying paperwork.
So, the goal is to prevent them from being able to dragnet low-level offenses for cheap. If you're a murder suspect and they have good reason to come after you, then they're coming after you irrespective of the cost.
Google is likely to have more legal resources to fend off unjust requests to access to your data.
We all know Google is doing it, though.
What, precisely, do we "know" Google/Microsoft/FUDCo is doing? Certainly not willingly collaborating with every quasi-legal search and seizure presented to them.
But you (or perhaps upthread) are implying that Google willingly hands over data to government authorities.
The evidence would point to the contrary: Google (and Microsoft I might add) are complying with the law, but are not simply rolling over and handing out whatever is asked of them.
Their ability to fight back against unwarranted requests is probably much better than someone running their own mail server in their basement.
I doubt that there is a way to build a webmailer without processing the emails content at some point. And as it is processed anyway; using it to adjust your ads doesn't appear to me as something significant.
It is disingenuous and/or ignorant to suggest that temporarily loading an email into memory for the purpose of displaying it on the users screen is the same as parsing and catagorising the text and storing the results of the analysis in a database for the purpose of manipulating the user.
I may be wrong, but I think they were referring to things like spam detection, malware detection, possibly search indexing, and such rather than just "temporarily loading an into memory for the purpose of displaying it."
At best, you could search headers if they aren't encrypted.
Until a viable ciphertext search scheme arrives. (there are some, but everyone I've seen has some caveat or hole)
I don't think users actually care though. Google's attempt to redefine "end-to-end encryption" to include decrypting something mid route bothered me. This... meh.
Still no comment on Turing?
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.
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?
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.
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?
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? ;-)
> There really should be some kind of standard or mail header though. :)
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 important-service@bigbank.com, it's that email claims to be from "Big Bank" <whoisthis@some.really.shady.ru>. 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.
DKIM authentication is in no way an attestation that it was sent by its sender. Furthermore, from what I can tell, more damage is caused by spoofing that works on the "I use a very similar name which is hard to see the difference" level (e.g., animenewsnetwork.com versus animenewssnetwork.com). Finding and testing solutions to that problem is something that doesn't require changing or deploying anything to new to the ecosystem, and it would arguably bring more benefit than deploying end-to-end encryption.
What do you think should be done to make progress that's better than Google's proposal? Personally I think encouraging all senders to adopt DKIM, transport layer TLS, DMARC, SPF, etc. by displaying auth results from those protocols in the UI is a good first step. It's similar to the push for HTTPS on the web.
> DKIM authentication is in no way an attestation that it was sent by its sender.
Google didn't mention DKIM in the blog post we're discussing. Are you referring to a related effort? The blog post was about encryption in transit with TLS.
> I'm arguing that the presentation of the data is at best meaningless and at worst downright harmful.
Google's DKIM solution is as close as one can reasonably get given modern technology. If I send a DKIM-signed email from example.com that passes validation, then it means the following is true: I sent an email through a server managed by the domain owner, that had access to the DKIM key and chose to sign my email. It's not authenticating a person, but it's authenticating that the domain's mail servers sent the message. The attestation is at the domain level, not the sender level. This attestation is still useful though: if the domain owner did not want to allow you to send email from jcranmer@example.com, then it would not accept that email from you or DKIM sign it.
a) An open source client that encrypts your mail b) A public key resource with a web-of-trust
All the major Web portals/ecosystems could lock the spooks out of email payloads very effectively. That would still leave other issues to solve, but securing payload in flight and at rest seems like the first real milestone that makes a difference.
Baby steps, people.
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.
From Google's perspective, it means they have to be involved, however non-consensually, in the process, rather than having it done to them transparently. So I can see why it's a win for them.
Whether it really matters to Joe Random User is arguable. What Joe User really ought to demand is end-to-end encryption rather than transit encryption, but he's unlikely to do that because key management across multiple devices (and who wants to read their email only on a single device?) is a pain and the companies that would be able to make it less of a pain aren't exactly incentivized to do so.
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/
There have been some mutterings in the IETF ProvReg WG on ways of allowing registrants some ability to automate the process, but it's still early days.
This is the best way of approaching that technology.
Verifying TLS for email is an easy step in making email a bit less insecure, and it requires no intervention from users. If you need something secure, then yes, go for GnuPG or other forms of end-to-end encryption (if only I could name a few).
You need gpg or s/mime to guard against that.
Which kind of medium do you have in mind? If you want a federated communication medium in wide use that doesn't require you to use proprietary software or a centralized server, there isn't much choice. This is why I'd say it's a worthwhile endeavor to make it possible to communicate securely and privately with email.
Securing email end-to-end is a solid step in the right direction towards making it work better for end-users.
#chillingeffect
Welcome to 2016
Fastmail (https://www.fastmail.com/)
Tutanota (https://tutanota.com/)
Riseup (https://help.riseup.net/)
Since you're in Tennessee (and thus a U.S. Person), you're actually ineligible for collection under FAA 702. Gmail/Hotmail/Yahoo, etc. would actually be the safest place for your information.
Of course that assumes that you believe the NSA follows U.S. law. If you don't have that assumption, that also implies that the NSA wouldn't respect Australian sovereignty enough to keep it from infiltrating Fastmail's servers.
I'm saying this to illustrate that there's no silver bullet for secure transmission and storage of information.
Nobody is arguing against search warrants. People are concerned about warrantless searches.
PS: I'm not related to Riseup.
These are good-for-the-user policies.
The not-being-authenticated indicator is just replacing any avatar with a question mark ("we're not sure this person is this person") and a tiny indicator that warns you that outgoing mail is sent in the clear.
As long as you're not sending mails to spam for this (which Google doesn't seem to be doing, unless of course a DMARC policy tells them to - I imagine) then I don't see the issue?
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.
https://googleonlinesecurity.blogspot.com/2014/06/making-end...
https://github.com/google/end-to-end
I don't know what they might do in the future to encourage people to use this, or if they feel that there's a point at which it would be sensible or useful to actively promote it.
There was an issue I was tracking a while back to integrate this support, but it's still a work in progress.
I'd never put any GPG keys of mine in an American cloud provider. That sort of voids the entire point of it.
On a somewhat related note, I remember reading some documentation on a one-time password scheme, which I can't find anymore. It briefly mentioned something about using DES calculators to handle crypto signatures (for what reason i cannot remember). For our purposes, a PGP/GPG hand-held device would be neat, though perhaps cumbersome to actually user.
Phone? Can we remotely trust nowadays smartphones not to have a number of backdoors?
Ultimately, what I envision would be a cross between a Blackberry (size, QWERTY keyboard) and the TI-83 (focus on being a simpler, lower-end computer). Heck, one may as well give it a unix-like OS and leave out wireless communications and sophisticated graphics. I think this is feasible, but the market would be quite small.
In fact, they will fight tooth and nail against it since their business model relies on having access to the plain text of the message. It's the very reason they are releasing this technology: a user sees a padlock icon that's confusing similar to other "encrypted" mail offerings, for example OpenPGP. For Google, it's essential that end-to-end encryption does not become the norm and that plain text emails are kept inside their walled garden.
That being said, as a form of opportunistic encryption, TLS on the SMTP layer is great and there are really no excuses not to use it in 2016. Google could push it aggressively and add an (user optional) delay against servers that try to deliver email over a plain connection: "472 Try again in 30 sec or use STARTTLS"
I search a lot.
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.
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."
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...
Though that would also prevent analysis of emails for ad targeting, so they'd have to do it as some sort of paid project.
Right now they're already telling you that they scan every email. So yeah, you would have to trust them that they do in-fact discard they keys and don't allow decryption in other scenarios. But large companies with tons of cash to lose if they're sued, will rarely blatantly lie about what they're doing.
Deleted comment
> 1. If you receive a message from, or are about to send a message to, someone whose email service doesn’t support TLS encryption, you’ll see a broken lock icon in the message.
> 2. 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.
AKA, it operates like the lock in my URL bar right now except in reverse. By the way Google has explained this feature, it seems fairly good to me. At least it doesn't say "this is secure" because, among other vulnerabilities, the remote server admin can still read what is received (as has always been the case with email).
Sysadmining was never that easy and was never intended to be done by the general public by clicking on a few 'continue' buttons and as the web is evolving, so is mail. Deal with it.
I would be more positive towards this if they gave precise, technical details of their notion of "supporting TLS" and "being authenticated", ideally with a service allowing me to test easily whether my mail server is fine according to them (rather than having to sign up for Gmail to test it).
I guess if nothing else, it would probably reduce spam!