Recent Posts

Harvesting Addresses from LinkedIn

There seems to have been an uptick in the number of folks harvesting addresses from their LinkedIn contacts and adding them to mailing lists. I’ve been seeing this in my own mailbox. I’m getting added to different lists and because I used a tagged address I know these folks are harvesting from LinkedIn.
This behavior is really rude. Just because someone accepted your contact request on LinkedIn, doesn’t mean they want to be added to any mailing lists you may have. Let’s be honest, some people have hundreds or thousands of LinkedIn contacts. They’re not going to want to get mail from all of them.
This behavior risks your ESP account. I know of ESPs who have disconnected customers for importing all their LinkedIn contacts.
Of course, there are ways to effectively use your LinkedIn contacts. The short version is think about what you’re doing and how your mail will be received. Don’t grab all your contacts, be selective about who you choose. Have too many contacts to go through manually? That’s not an excuse, in fact, it’s an even bigger argument for not becoming a spammer.

I’ve previously written things you must consider when sending bulk mail to people who have connected with you on social networks.

Spam filtering is apolitical

It’s time once again for news organizations to pay attention to spam filters. This happens sometimes. Intrepid news organizations breathlessly report on how a particular ISP is blocking mail from a certain political figure our organization. I’ve written about political and activist lists being blocked or filtered before. Some of these posts are from the very early days of the blog even.

In 2007, AOL came under fire when their filters were blocking mail from Truthout.org. Truthout’s response was to yell, loudly, this was censorship and unfair. I talked about it in two blog posts: They’re not blocking you because they hate you and It really can be your email.
The reality is mail wasn’t blocked because AOL didn’t like Truthout or what they stood for. In fact, the folks I knew at the postmaster desk who handled blocking issues were more likely to support Truthout than try and censor them. But, the reality was that truthout.org was sending bad mail and it wasn’t wanted and so it got filtered. Don’t believe me? Carl Hutzler ran the AOL postmaster team and blogged about it at the time. His blog is gone, but archive.org has the full text.

Bad data drives delivery problems

It’s a wild election season here in the US. In the past few presidential elections, email has played a bigger and bigger role in messaging and fundraising. President Obama’s campaign used email effectively, but sent huge volumes. In fact, the volume was so heavy, it led to a joke on the Daily Show.

Bounce handling is hard

Sometimes I find it hard to find a new topic to write about. I decide I’m going to write about X and then realize I did, often more than once. Other times I think I can blog about some issue only to realize that it’s too complex to handle in a quick post. There are concepts or issues that need background or I have to work a little harder to explain them.
One thing I haven’t blogged about before is bounce handling. That particular topic falls into the other category of posts that take a lot of time to write and need a significant amount of work to make sense. I was even joking with my fellow panel members at EEC a few months ago about how that’s a post that so needs to be written but I’m avoiding it because it’s so hard. There’s so much to be conceptualized and explained and I realize it’s not a blog post but multiple blog posts, or a white paper or even a book.

So let’s start with some simple definitions. Those of you who work at ISPs are probably thinking of bounces in terms of accept than reject, that’s not exactly what I’m talking about here. I’m writing these for senders, who usually call rejects during the SMTP transaction bounces.

Comodo, TLS certificates and business ethics

We run a lot of our own infrastructure at Word to the Wise. Our email and web presence runs on our own hardware, in our own cabinet in our own network space. Partly that’s because we’re all from very technical backgrounds, and can run them in a way that’s better suited to our needs than an off-the-shelf web service. Partly it’s so we can do things like add instrumentation to our inbound mail stream so we have easy access to information when diagnosing a customer’s delivery issues. But it’s also partly so we can keep up to date on protocols and software, and leaven our advice to clients with some first hand, real world experience.
One of those things is TLS certificates, for webservers and email servers.
We already used Comodo for code-signing certificates, so when their sales rep called me and offered some decent pricing of extended validation (EV or “green bar”) certificates in exchange for a three-year commitment that seemed like a good opportunity to experience the extended validation process.
I’ve written previously about how painful the process of getting a TLS certificate from a legacy certification authority such as Comodo is, but this post isn’t about that.
I mentioned a few months ago that our green bar TLS certificate would be going away. That was because Comodo didn’t honor their agreement with us. While we ordered three years of EV certificate from Comodo, paid them for three years of EV certificate and confirmed in writing with the sales rep that they would provide three years of EV certificate, after one year Comodo decided that they wouldn’t honor that agreement.
The sales rep was mysteriously “no longer with the company” and his sales manager decided that they’d keep the money, but not provide the agreed to certificates. After a dozen or so promised calls back or email replies from a “sales manager” to discuss “what they could do for us” didn’t happen, we gave up on Comodo and switched to using Lets Encrypt for our TLS certificates.
We’re very, very happy with Let’s Encrypt. The price of “free” is nice, but it’s the simplicity, reliability and general lack of having to deal with horrible sales reps that’s the best thing.
Apparently a lot of other Comodo customers thought the same thing, as Comodo seems to want to recapture those customers by pretending to be Let’s Encrypt. They filed trademark registrations for “Let’s Encrypt”, “Comodo Let’s Encrypt” and “Let’s Encrypt with Comodo”. Comodo is in the business of “trust” and “identity” and I can’t think of any behaviour of theirs more antithetical to that.
And, on an email note, Comodo also seemed to decide that they didn’t want their employees to know about this, nor to answer questions about it, and reportedly configured their email filters to reject email mentioning letsencrypt.org with “mail contains a virus”.

— from Peter Stenberger, on twitter
(Given Comodo are a major email filter vendor I hope that that’s just a local configuration used by Comodo themselves, not part of their public filtering products.)
We will no longer be using or recommending Comodo as a vendor.
(This post brought to you as an exercise in avoiding the question “What effect will brexit have on the email industry?”, as the answer “Global economic collapse would probably be bad for the email industry, yes.” seems a little simplistic.)

Domain transparency

An email I received this morning got me thinking about how your domain name is one of the main ways you identify yourself if you’re sending email.
We talk about domain reputation quite a lot – DKIM and SPF let a sender volunteer a domain name as a unique identifier for recipients to use to track reputation, DMARC allows them to tie that domain to the domain visible to the user in the From: field. And most ISPs use the domains in links in the body of the message to track reputation, either internally or through third-party reputation providers.
trust
But there’s also a human side. We expect people and companies to be honest in how they identify themselves – and we’re suspicious when they aren’t. We’ve been trained to be wary of messages that claim to be from a company we know but which, for whatever reason, don’t look quite right. Rightly so – a lot of phishing and credential theft is based on bad people using branding and domains that look like legitimate ones.
Here are some header snippets from this morning’s (legitimate) email:

iOS mail supporting list-unsub header

Al over at SpamResource reports that the next generation of Apple’s iOS has support for the list unsubscribe header.
To the best of my knowledge, this is the first time an independent email client has built in support for the List-Unsubscribe header. Microsoft and Google support it, but only in their webmail system. Hopefully other mail clients will follow suit.

Role accounts

A question came up on a recent deliverability panel about role accounts.

Sanford Wallace goes to Jail

Sanford Wallace has been sentenced to 2 years in jail by the US District court in San Jose for contempt of court and electronic mail fraud. Sanford has been around for more than 2 decades. He is one of the spammers that drove me to learn how to read headers and report spam back in the late nineties.

Sanford has been in and out of courts and the news almost as long as he’s been spamming. When I dug into Pacer this morning to grab a copy of the sentencing report I see multiple cases, some going back as far as 1996. There aren’t electronic records for Concentric Network v. Wallace, et al. (case: 5:96-cv-20829-RMW) but the final disposition of the case says “Permanent Injunction.”

About that permission thing

I wrote a few days ago about permission and how it was the key to getting into the inbox. It’s another one of those “necessary but not sufficient” parts of delivery. There are, however, a lot of companies who are using email without the recipient permission. These companies often contact me to help them solve their delivery problems. Often these are new companies who are trying to jumpstart their business on the cheap by using email.

The calls have a consistent pattern.