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.

Related Posts

Dealing with blocklists, deliverability and abuse people

There are a lot of things all of us in the deliverability, abuse and blocklist space have heard, over and over and over again. They’re so common they’re running jokes in the industry. These phrases are used by spammers, but a lot of non-spammers seem to use them as well.
The most famous is probably “I’m sure they’ll unblock me if I can just explain my business model.” Trust me, the folks blocking your mail don’t want to hear about your business model. They just want you to stop doing whatever it is you’re doing. In fact, I’m one of the few people in the space who actually wants to hear about your business model – so I can help you reach your goals without doing things that get you blocked.
A few months ago, after getting off yet another phone call where I talked clients down from explaining their business model to Spamhaus, I put together list of phrases that senders really shouldn’t use when talking to their ESP, a blocklist provider or an abuse desk. I posted it to a closed list and one of the participants put it together into a bingo card.
bingo__email__save_1
A lot of these statements are valid marketing and business statements. But the folks responsible for blocking mail don’t really care. They just want their users to be happy with the mail they receive.

Read More

Confirmed Opt-In: An Old Topic Resurrected

Looking back through my archives it’s been about 4 years or so since I wrote about confirmed opt in. The last post was how COI wasn’t important, but making sure you were reaching the right person was important. Of course, I’ve also written about confirmed opt-in in general and how it was a tool somewhat akin to a sledgehammer. I’m inspired to write about it today because it’s been a topic of discussion on multiple mailing lists today and I’ve already written a bunch about it (cut-n-paste-n-edit blog post! win!).
Confirmed opt-in is the process where you send an email to a recipient and ask them to click on a link to confirm they want the mail. It’s also called double opt-in, although there are some folks who think that’s “spammer” terminology. It’s not, but that’s a story for another day. The question we were discussing was what to do with the addresses that don’t click. Can you email them? Should you email them? Is there still value in them?

We have to treat the addresses as a non-homogenous pool. There are a lot of reasons confirmation links don’t get clicked.

Read More

Truth of Consequences

“If you want to use another means that violates the law, and every common definition of “spam”, then by all means, go ahead. You can enjoy fines and being added to the ROKSO database,” says a comment on my recent COI blog post. It’s both disconcerting and entirely predictable.

My post was a discussion of what to do with addresses that don’t confirm. Data tells us that there is some value in those addresses – that there are people who won’t confirm for some reason but will end up purchasing from an email. Using COI leaves some fraction of revenue on the table as it were. My post was a short risk analysis of things to think about when making decisions about continuing to mail to people who don’t confirm.
Mentioning COI often brings the only-COI-mail-is-not-spam zealots out of the woodwork, as it did in this case. In this case, we have the commenter first asserting that failure to do COI is a violation of CAN SPAM (it’s not). When this was pointed out, he started arguing with two people who have been actively fighting spam for 20 years (including running a widely used blocklist). Finally, he ends up with the comment asserting that anyone not using COI will end up on ROKSO. It’s as if he thinks that statement will fear other commenters into not having opinions. It can’t because everyone in the discussion, except possibly him, knows that it’s not true.
The worst problem with folks like the commenter is that they think asserting horrible consequences will make people cower. First off, people don’t react well to threats. Secondly, this is a hollow threat and most people reading this blog know it.
There are millions of mailing lists not using COI and have zero risk of ever getting on ROKSO. The only thing hollow threats do is make people not pay attention to what you have to say. Well, OK, and have me write a blog post about how those threats are bad because they’re completely removed from reality.
Exaggerating or lying about consequences is not just wrong, it’s stupid. “Do this or else BAD THING,” is awesome, up until someone decides they’re not going to do this and the bad thing never happens. It makes people less likely or pay any attention to you in the future. It certainly means your opinions and recommendations are not going to be listened to in the future.
I probably go too far the other direction. I can spend too much time contextualizing a recommendation. It’s one of the things I’m trying to get better about. No, client doesn’t need a 4 page discussion of the history of whatever, they just need 2 lines of what they should do. If they need the context, I can provide it later.
In order to effectively modify behavior consequences have to be real. Threats of consequences are meaningless. Any toddler knows this, and can quite accurately model when mom means it and when she’s just threatening.
Risk analysis is not about modifying behavior. It’s about analyzing a particular issue and providing necessary information so the company action understands potential consequences and the chance those risks will happen. The blog post about COI was not intended to modify anyone’s behavior. I know there are companies out there successfully maintaining two mail streams: one COI and one not. I know there are other companies out there successfully mailing only single opt-in mail. I know there are companies with complex strategies to verify identity and address ownership. And I smile every time I walk into a retail store and they ask me if my email address is still X and if I want to make any changes to it.
Lying about consequences does nothing to modify behavior. All it does is diminish the standing and audience of the liar. Be truthful about the consequences of an action or lack of action. Don’t make up threats in order to bully people into doing what you think is right. Sooner or later they’re going to realize that you don’t know what you’re talking about and start to ignore you.

Read More