Recent Posts

Mandatory TLS is coming

Well, not exactly mandatory but Chrome will start labeling any text or email form field on a non-TLS page as “NOT SECURE”.

Chrome 62 will be released as stable some time around October 24th. If you want to avoid the customer support overhead then, regardless of whether any of the information on a form is sensitive, you should probably make sure that all your forms are accessible via TLS and redirect any attempt to access them over plain http to https. You can do that globally for a whole site pretty easily, and there’s not really any downside to doing so.
I still have half a dozen sites I need to convert to supporting TLS – the cobbler’s children have no shoes – and I’m beginning to feel a little urgency about it.
There’s more information in Google’s announcement, their checklist of how to set up TLS, and some background at Kaspersky Labs.

Maybe they're just not that into you?

In April of last year I created a new twitter account. I can’t remember exactly why, but it was a throwaway created to look at some aspect of how twitter interacts with new accounts.
As part of the account creation process I gave Twitter an email address. They sent me a confirmation message right away:

I didn’t click the button.
Four months later they sent me another confirmation email. I didn’t click the button.
It’s now sixteen months later. Nobody has logged in to or interacted with that twitter account since the day it was created. Twitter are sending me confirmation messages for that account about once a month.
They’re doing quite a lot of things right – they have not just an “Opt-out” link but also a “Not my account” link, which is great!
But after sixteen months of not returning your messages, maybe they’re just not that in to you?

Local-part Semantics

An email address has two main parts. The local-part is the bit before the @-sign and the domain is the bit after it. Loosely, the domain part tells SMTP how to get an email to the destination mailserver while the local part tells that server whose mailbox to put it in.
I’m just looking at the local part today, the “steve” in “steve@example.com”.
Talkin’ ‘Bout a Specification
The original specification for SMTP email delivery, RFC 821, specifies a few things about the local-part. It can’t be more than 64 character ascii characters long, and it must be wrapped in double quotes if it includes any punctuation. But that’s just syntax, nothing to do with what it means. It does mention that it’s case-sensitive: “steve@example.com” is not the same recipient as “sTeve@example.com”.
The specification for the structure of email messages, RFC 822, tells us a little more. It clarifies that the local-part is case-sensitive, with the sole exception of the “postmaster” account, which is required to be deliverable as “postmaster”, “POSTMASTER”, “POSTmasTER” or any other variant you like.

Aug 21, 2017

August mini-recess

Blogging will be light through the end of the month. We’re headed to Wyoming to see the eclipse this weekend. As well, with all of the current political events happening it’s hard to focus on email right now.
So basically I’m giving myself permission to not blog daily through the end of August. I’ll blog as I have stuff to say. Some of those might be copies and pastes from comments I’ve made in other spaces. I seem to be on FB quite a bit these days – sometimes even email related.
I’ve also been asking questions and discussing stuff on some mailing lists. I had a flash of insight about how I think about deliverability differently from other people and am talking with some colleagues about it to make sure I can explain it well.

Email address as identity

A few months ago I was talking about different mailbox tools and mentioned email addresses are the keys to our online identity. They are, email addresses are the magic key that authenticates us and opens access to different accounts.
The bad guys know this too. The Justice department recently announced a plea deal related to compromised email accounts. The individual in question gained access to faculty, staff and student email accounts. They then used access to these accounts to access Facebook, iCloud, Google, LinkedIn and Yahoo accounts.
https://twitter.com/pwnallthethings/status/897930523120738304
https://twitter.com/pwnallthethings/status/897931383431061504
https://twitter.com/pwnallthethings/status/897932050111406081
Mediapost published an article this week referencing a survey performed at this year’s BlackHat conference.

Reengagement emails

By default I don’t load images in email. For one thing it lets me see who is using open / click data to measure engagement. This morning I got a reengagement email from my Senator.

There are things I really like about this email and there are somethings I think they get a little wrong.

State of Email Deliverability

I had other posts in the pipeline, but saw a link to the Litmus 2017 State of Email Deliverability Report and decided that deserved a mention here.
There’s all sorts of interesting data there, and well worth a download and read. I was, of course, interested in the “most problematic subscriber acquisition sources.” Senders having blocking issues or blacklist problems in the past 12 months use list rental, co-reg and purchased lists more often than senders that didn’t have problems.

Senders acquiring addresses through list rental are 104% more likely to be blacklisted than senders not using list rental. And they’re 47% more likely to be blocked.
These stats are the primary reason that most ESPs don’t allow list rentals, purchased or co-reg lists. They cause blocking and blacklisting. The ESP ends up having to deal with lots of problems and clean up the mess.
I’m unsurprised that lead generation by giving something away (a report, ebook, whatever) is related to problems. Most of these forms do little to no data checking and accept any and all fake data. There are fairly simple ways to enforce better data, but that does limit the spread of the information.
I am surprised to see signup through direct mail and catalog sales is so bad. Unless maybe people don’t know how to say no when asked for an email address over the phone. I know it seems awkward to say no when asked for an email address. Maybe some folks are giving fake addresses. I sometimes say I don’t have email, or just tell them no, they don’t need one.
The white paper itself is well worth a read. Go download it yourself (but don’t give them a fake email address!).

Not a customer you want

Earlier this week one of my ESP clients contacted me. They have a new (potential?) customer dealing with some delivery challenges. Client was looking for advice on how to move the customer over and improve their delivery at the same time.
My advice was actually pretty simple: this isn’t a customer you want. Walk away.
I reached that conclusion about 10 seconds after I loaded the customer’s website. Because I know sometimes initial impressions are wrong, I did spend about 10 more minutes poking around. What I found did nothing to change my mind or convince me my initial impression was wrong. In fact, everything I found reinforced the belief that this was not a good customer for my client.
I sent my client an email explaining what I’d found and they agreed. Future deliverability problem averted!
Some of what I found inspired the conversations with spammers blog post from earlier this week. For instance, the website had two different signup forms, each pointing to a different ESP. Both links were dead.

Then I looked at the company’s whois record and found a bunch of cookie cutter websites, all with different domain names, all with the same broken subscription links.
I do this manually and I can’t fathom how you would automate this kind of checking. For me, it seems there absolutely needs to be a human in the loop. But I suspect that there are ways to automate these types of checks.
In any case, there’s a spammer looking for an email service provider. He’s having problems with IP reputation at his current ESP. He sends content and will even share with you the domain he’s using to collect email addresses. Pro tip: try and sign up for his mail before he signs your contract.

Conversations with spammers

It’s amazing how many spammers try and fool deliverability into accepting a questionable list. All too often they fall back on a story. The basic points: a company you’ve never heard of collected millions of email addresses on a website hosted on a low end VPS.

I’ve never heard of your company. We’re just that much better at marketing. This list is guaranteed 100% opt in. Subscribers are desperate to hear from us. The mail is vital and important. We had some problems at our last ESP, but that’s just because they don’t understand our business model. And we had a brief problem with complaints. But they weren’t real complaints. Our competitors are signing up for the list and complaining to hurt out business. It’s not a list problem, it’s that we’re so dominant they have to subvert us. That’s just because we’re that much better at their jobs than anyone else.
You’re looking for deliverability help. Well, yeah, sometimes Gmail delivery is bad, but that’s simply because we won’t pay Google money for advertising. Google is so afraid of us they deliberately filter all this spectacularly wanted email into the bulk folder. They have problems with us as a business. Oh, and we might, sometimes, occasionally have a minor problem with Yahoo. But, again, it’s because we threaten them and they don’t want to have to compete on a level playing field.
If they’re a potential customer, I tell them about our services and offer a proposal. Once some company I’ve never heard of tells me their bad delivery is because global companies are afraid of them, there’s really nothing I can do. They’re unlikely to listen to me explain reality to them.
Sometimes, though, this conversation happens because I’m consulting for an ESP or an Agency. They’ve brought me in to discuss deliverability with a customer or vendor. In those cases, it’s my job to keep going.
Your site doesn’t actually have a signup form. That’s because we’re in the middle of an upgrade cycle and had some problems with the back end. [Alternative: We stopped collecting new email addresses because of their deliverability problems and removed the form.] Your site has a signup form, and I signed up, but never got any mail from you. We disconnected the signup form while we handle our deliverability problems. [Alternative: That shouldn’t happen. We can forward you some messages instead.] I have received spam advertising your company. We had a rogue affiliate that we discovered was spamming and we cut them off.
No, this is direct from your IP space. Oh, well, you must have opted in and forgotten about it. [Alternative: We had a rogue sales guy, but we fired him for spamming.] Your company has only been in business for 3 years, this is an address I haven’t used since the ’90s. Oh, we probably bought a company that you opted into and so have permission that way.
That’s not really permission. Of course it is!
OK…. How can I help you. We want you to call Google / Yahoo / Hotmail and tell them we’re really a legitimate company that’s sending content and we shouldn’t be in the bulk folder.
What have you changed? Nothing! Why would we change anything? We’re great marketers. We have all these plans but need to get back to the inbox before we can implement them.
Um… there’s no filter setting for “laura says they’re a good sender.” They’re going to look for new sending patterns so let’s change a few things. Well, we recently removed 2/3 of our database, but it made no difference so we don’t know what else you think we can do.
Let’s talk about your technical setup.