May 2016: The Month in Email

Summer, already? Happy June! Here’s a look at our busy month of May.
201605Wrapup
I had a wonderful time in Atlanta at the Salesforce Connections 2016 conference, where I spoke on a panel about deliverability. While in Atlanta, I also visited our friends at Mailchimp, and later spoke at the Email Innovations conference in Las Vegas, where I did my best to avoid “explaining all the things”. Since my speaking schedule for 2017 is filling up already, I’m sure I’ll have plenty of opportunity to explain many more of the things over the next year or so. Let me know if there’s an event that might be a good fit for me, either as a keynote speaker or on a panel.
Steve contributed a few technical posts on the blog this month. He mentioned that Google has stopped supporting the obsolete SSLv3 and RC4, and he explored the ARC protocol, which is in development and review, and which will be useful in extending authentication through the email forwarding process.
Meri contributed to the blog this month as well, with a post on the Sanders campaign mailing list signup process. We’ve written about best practices for political campaigns before, and it’s always interesting to see what candidates are doing correctly and incorrectly with gathering addresses and reaching out to supporters.
In other best practices coverage, I pointed to some advice for marketers about authentication that I’d written up for the Only Influencers list, a really valuable community for email marketers. I wrote about purchased lists again (here’s a handy collection of all of my posts on the topic, just in case you need to convince a colleague that this isn’t a great idea). I also wrote about how getting the technical bits right isn’t always sufficient, which is also something I’ve written about previously. I also discussed the myth of using the word “free” in the subject line. As I said in the post, “Single words in the subject line don’t hurt your delivery, despite many, many, many blog posts out there saying they do. Filters just don’t work that way. They maybe, sorta, kinda used to, but we’ve gotten way past that now.”
On a personal note, I reminisced about the early days of mailing list culture and remembered a dear online friend as I explained some of why I care so much about email.
In my Ask Laura column, I covered CAN SPAM and transactional opt-outs. As always, if you have a general question about deliverability that I can answer in the column, please let me know.

Related Posts

What is Two Factor Authentication?

Two factor authentication, or the snappy acronym 2FA, is something that you’re going to be hearing a lot about over the next year or so, both for use by ESP employees (in an attempt to reduce the risks of data theft) and by ESP customers (attempting to reduce the chance of an account being misused to send spam). What is Authentication?
In computer security terms authentication is proving who you are – when you enter a username and a password to access your email account you’re authenticating yourself to the system using a password that only you know.
Authentication (“who you are”) is the most visible part of computer access control, but it’s usually combined with two other A’s – authorization (“what you are allowed to do”) and accounting (“who did what”) to form an access control system.
And what are the two factors?
Two factor authentication means using two independent sources of evidence to demonstrate who you are. The idea behind it is that it means an attacker need to steal two quite different bits of information, with different weaknesses and attack vectors, in order to gain access. This makes the attack scenario much more complex and difficult for an attacker to carry out.
It’s important that the different factors are independent – requiring two passwords doesn’t count as 2FA, as an attack that can get the first password can just as easily get the second password. Generally 2FA requires the user to demonstrate their identity via two out of three broad ways:

Read More

Defending against the hackers of 1995

Passwords are convenient for the end user, but it’s too easy to lose control of them. People share them with other people. People write them down, where they can be read. People send them in email, and that email is easily intercepted. People’s web browsers store the passwords, so they can log in automatically. Worst of all, perhaps, people tend to use the same username and password at many different websites. If just one of those websites is compromised (or even run as a password collecting scam) then those passwords can be used to attack accounts at all of the others.
Two factor authentication that uses an uncopyable physical device (such as a cellphone or a security token) as a second factor mitigates most of these threats very effectively. Weaker two factor authentication using digital certificates is a little easier to misuse (as the user can share the certificate with others, or have it copied without them noticing) but still a lot better than a password.
Security problems solved, then?

Read More

More on ARC

ARC – Authenticated Received Chain – is a way for email forwarders to mitigate the problems caused by users sending mail from domains with DMARC p=reject.
It allows a forwarder to record the DKIM authentication as they receive a mail, then “tunnel” that authentication on to the final recipient. If the final recipient trusts the forwarder, then they can also trust the tunneled DKIM authentication, and allow the mail to be delivered despite the DMARC p=reject published by the sending domain.
The specification and interoperability testing are progressing nicely and it’s definitely going to be useful for discussion list operators and vanity forwarders soon. It’s not something that’s as likely to help ESPs targeting small organizations and individuals, so all y’all shouldn’t be holding your breath for that.
There’s a more information about it at arc-spec.org and they’ve just published a great presentation with a technical overview of how it works:

Read More