Google drops obsolete crypto

Google is disabling support for email sent using version 3 of SSL or using the RC4 cypher.
They’re both very old – SSLv3 was obsoleted by TLS1.0 in 1999, and RC4 is nearly thirty years old and while it’s aged better than some cyphers there are multiple attacks against it and it’s been replaced with more recent cyphers almost everywhere.
Google has more to say about it on their security blog and if you’re developing software you should definitely pay attention to the requirements there: TLS1.2, SNI, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, DNS alternate names with wildcards.
For everyone else, make sure that you’ve applied any patches your vendor has available well before the cutoff date of June 16th.

Time for Email Innovations!
SHOUTY CAPS!!!

Related Posts

Google Apps for ISPs is gone

Google Apps for ISPs is being shut down. While this was a scheduled end of life, apparently some users weren’t notified (always keep the contact email address up to date at your vendor!) and other users were told that it would be discontinued in July and were surprised when their service was turned off a month earlier than they expected.
I’ve not seen any reports of mail bouncing due to this yet, but it’s likely that some consumer ISPs will be scrambling to migrate to new email providers and their inbound mail may be a mess for a while. If you see domain-wide problems at consumer domains, check to see if their MXes point at the google aspmx cluster.
It seems to be a rolling shutdown, and some ISPs have apparently had their service extended by a few days or weeks, so issues may start with some domains throughout the month.

Read More

Protect your email with TLS

You probably use TLS hundreds of times a day. If you don’t recognize the term, you might know it better by it’s older name, SSL.
TLS is what protects your data in transit whenever you go to Google, or Yahoo or even this blog. The little padlock in your browser address bar tells you that your browser has used the TLS protocol to do two things. First, it’s decided that the server you’re connecting to really is operated by Google, or Yahoo or us – you’re (probably) not having your session intercepted by someone in the middle between you and the webserver, either to read your traffic or modify it en-route. Second, it is encrypting all the traffic between you and the webserver, so that it can’t be passively monitored while in transit. Because of concerns about ubiquitous surveillance many websites – including ours – are moving to use TLS for everything, not just for protecting a login page or a credit card number.
That’s great for the web, but how does it apply to email? One place it’s used is for connections between your mail client and your local mailserver – sending mail to the smarthost via [rfc 4409]SUBMIT[/rfc] and fetching mail using [rfc 2595]IMAP or POP3[/rfc] almost always use TLS. That protects the privacy of your messages between you and your ISP and also protects the username and password you use to authenticate with.
Mail traveling between ISPs didn’t used to be encrypted “on the wire” , but about 15 years ago [rfc 3207]an extension to SMTP was proposed[/rfc] that would allow ISPs to negotiate during each session whether they should encrypt it or not. This extension, often referred to as STARTTLS after the command it uses, allows gradual rollout of encryption of mail traffic between ISPs without requiring any sort of flag day. A mailserver that supports STARTTLS will tell everyone who connects to it “Hey! I support STARTTLS!”. When a smarthost that also supports it connects to that mailserver it will go “Great! I support STARTTLS too! Lets do this!” and convert the plain text SMTP session into an encrypted session protected by TLS.
Fifteen years seems like a long period in Internet time, but non-intrusive protocol changes can take a long time to deploy. Facebook Engineering have done the work to see how that deployment is going with their survey of the current state of SMTP STARTTLS deployment. The results are really quite positive – over three quarters of the mailservers they sent mail to supported STARTTLS, covering nearly 60% of their users. That’s definitely enough to make supporting STARTTLS worthwhile.
More about TLS and encryption tomorrow.

Read More

December 2014: The month in email

2014 has been a busy and exciting year at Word to the Wise (look for more on that in a year-end wrap-up post next week!) and this month was particularly thrilling for us as we officially doubled our size with the addition of Josh and Meri on our client services team.
If you’re a regular reader of our blog, you’ve probably spotted Josh’s byline on a few posts: Google’s Inbox Team answers questions on Reddit, which looks at what this new email client portends for both consumers and email marketers, and M3AAWG Recommends TLS, which reviews M3AAWG’s recommendation that mailbox providers phase out SSL encryption in favor of TLS. Look for more smart insights from Josh in 2015.
Steve contributed a post on the proper syntax for displaying a friendly email address, and a very helpful guide for generating useful test data that doesn’t compromise personally identifiable information from your actual customer data. He also detailed the brief DBL false positive from Spamhaus’ new “Abused-Legit” sub-zone and best practices for handling unrecognized responses.
I wrote about some of the subtleties inherent in how brands decide to “converse” with customers in email and other channels. We’ll just keep saying it: companies need to respect the inbox as personal space. I want to thank both Steve and Josh for picking up my slack on blogging. 7+ years is a long time to try and say new things on the blog and I needed a bit of a break.

Read More