Recent Posts

Do you run spam filters?

Jan Schaumann is putting together a talk on ethics in as related to folks managing internet operations. He has a survey and is looking for folks who wrangle the machines that run the internet. I’m copying his post, with permission, due to a slightly NSFW image on his announcement.

Reputation is about behavior

Reputation is calculated based on actions. Send mail people want and like and interact with and get a good reputation. Send mail people don’t want and don’t like and don’t interact with and get a bad reputation.

Reputation is not
… about who the sender is.
… about legitimacy.
… about speech.
… about message.
Reputation is
… about sender behavior.
… about recipient behavior.
… about how wanted a particular mail is forecast to be.
… based on facts.
Reputation isn’t really that complicated, but there are a lot of different beliefs about reputation that seem to make it complicated.
The reputation of a sender can be different at different receivers.
Senders sometimes target domains differently. That means one receiver may see acceptable behavior but another receiver may see a completely different behavior.
Receivers sometimes have different standards. These include standards for what bad behavior is and how it is measured. They may also have different thresholds for things like complaints and bounces.
What this means is that delivery at one receiver has no impact on delivery at another. Just because ISP A delivers a particular mail to the inbox doesn’t mean that ISP B will accept the same mail. Each receiver has their own standards and sometimes senders need to tune mail for a specific receiver. One of my clients, for instance, tunes engagement filters based on the webmail domain in the email address. Webmail domain A needs a different level of engagement than webmail domain B.
Public reputation measures are based on data feeds.
There are multiple public sources where senders can check their reputation. Most of these sources depend on data feeds from receiver partners. Sometimes they curate and maintain their own data sources, often in the form of spamtrap feeds. But these public sources are only as good as their data analysis. Sometimes, they can show a good reputation where there isn’t one, or a bad reputation where there isn’t one.
Email reputation is composed of lots of different reputations.
Email reputation determines delivery. Getting to the inbox doesn’t mean sending from an IP with a good reputation. IP reputation is combined with domain reputation and content reputation to get the email reputation. IP reputation is often treated as the only valuable reputation because of the prevalence of IP based blocking. But there are SMTP level blocks against domains as well, often for phishing or virus links. Good IP reputation is necessary but not sufficient for good email delivery.
Reputation is about what a sender does, not about who a sender is.
Just because a company is a household name doesn’t mean their practices are good enough to make it to the inbox. Email is a meritocracy. Send mail that merits the inbox and it will get to recipients. Send email that doesn’t, and suffer the repercussions.

Organizational security and doxxing

The security risks of organizational doxxing.
These are risks every email marketer needs to understand. As collectors of data they are a major target for hackers and other bad people. Even worse, many marketers don’t collect valid data and risk implicating the wrong people if their data is ever stolen. I have repeatedly talked about incidents where people get mail not intended for them. I’ve talked about this before, in a number of posts talking about misdirected email. Consumerist, as well, has documented many incidents of companies mailing the wrong person with PII. Many of these stories end with the company not allowing the recipient to remove the address on the account because the user can’t prove they own the account.
I generally focus on the benefits to the company to verify addresses. There are definite deliverability advantages to making sure email address belongs to the account owner. But there’s also the PR benefits of not revealing PII attached to the wrong email address. With Ashley Madison nearly every article mentioned that the email address was never confirmed. But how many other companies don’t verify email addresses and risk losing personally damaging data belonging to non customers.
Data verification is so important. So very, very important. We’ve gone beyond the point where any big sender should just believe that the addresses users give them are accurate. They need to do it for their own business reasons and they need to do it to prevent incorrect PII from being leaked and shared.

It's not about the spamtraps

I’ve talked about spamtraps in the past but they keep coming up in so many different discussions I have with people about delivery that I feel the need to write another blog post about them.
Spamtraps are …
… addresses that did not or could not sign up to receive mail from a sender.
… often mistakenly entered into signup forms (typos or people who don’t know their email addresses).
… often found on older lists.
… sometimes scraped off websites and sold by list brokers.
… sometimes caused by terrible bounce management.
… only a symptom …

Thank You

Today will be my last day at Word to the Wise. I joined WttW in December of 2014, and it has been a wonderful journey. I have enjoyed working with Laura, Meri, and Steve, and I’ve enjoyed working with all of our clients helping solve their deliverability challenges.
Laura has such a deep understanding and knowledge of deliverability that every day I would find myself learning from her and trying to soak in as much as possible. Steve has extensive experience on the technical side of things, which helped when troubleshooting those pesky DNS issues. Meri is the glue that keeps everything together and is always willing to contribute.
WttW has some exciting things in the pipeline, and I have no doubt they will be very successful. I wish nothing but the best for WttW, and I will miss working with everyone. Thank you WttW for a wonderful learning experience.

Your system; your rules

In the late 90s I was reasonably active in the anti-spam community and in trying to protect mailboxes. There were a couple catchphrases that developed as a bit of shorthand for discussions. One of them was “my server, my rules.” The underlying idea was that someone owned the different systems on the internet, and as owners of those systems they had the right to make usage rules for them. These rules can be about what system users can do (AUPs and terms of service) or what about what other people can do (web surfers or email senders).
I think this is still a decent guiding principle in “my network, my rules”. I do believe that network owners can choose what traffic and behavior they will allow on their network. But these days it’s a little different than it was when my dialup was actually a PPP shell account and seeing a URL on a television ad was a major surprise.
But ISPs are not what they once were. They are publicly owned, global companies with billion dollar market caps. The internet isn’t just the playground of college students and researchers, just about anyone in the US can get online – even if they don’t own a computer there is public internet access in many areas. Some of us have access to the internet in our pockets.
They still own the systems. They still make the rules. But the rules have to balance different constituencies including users and stockholders. Budgets are bigger, but there’s still a limited amount of money to go around. Decisions have to be made. These decisions translate into what traffic the ISP allows on the network. Those decisions are implemented by the employees. Sometimes they screw up. Sometimes they overstep. Sometimes they do the wrong thing. Implementation is hard and one of the things I really push with my clients. Make sure processes do what you think they do.
A long way of dancing around the idea that individual people can make policy decisions we disagree with on their networks, and third parties have no say in them. But those policy decisions need to be made in accordance with internal policies and processes. People can’t just randomly block things without consequences if they violate policies or block things that shouldn’t be blocked.
Ironically, today one of the major telcos managed to accidentally splash their 8xx number database. 8xx numbers are out all over the country while they search for backups to restore the database. This is business critical for thousands of companies, and is probably costing companies money right and left. Accidents can result in bigger problems than malice.

August 2015: The month in review

It’s been a busy blogging month and we’ve all written about challenges and best practices. I found myself advocating that any company that does email marketing really must have a well-defined delivery strategy. Email is such vital part of how most companies communicate with customers and potential customers, and the delivery landscape continues to increase in complexity (see my post on pattern matching for a more abstract look at how people tend to think about filters and getting to the inbox). Successful email marketers are proactive about delivery strategy and are able to respond quickly as issues arise. Stay tuned for more from us on this topic.
I also wrote up some deliverability advice for the DNC, which I think is valuable for anyone looking at how to maintain engagement with a list over time. It’s also worth thinking about in the context of how to re-engage a list that may have been stagnant for a while. A comment on that post inspired a followup discussion about how delivery decisions get made, and whether an individual person in the process could impact something like an election through these delivery decisions. What do you think?
As we frequently point out, “best practices” in delivery evolve over time, and all too often, companies set up mail programs and never go back to check that things continue to run properly. We talked about how to check your tech, as well as what to monitor during and after a send. Josh wrote about utilizing all of your data across multiple mail streams, which is critical for understanding how you’re engaging with your recipients, as well as the importance of continuous testing to see what content and presentation strategies work best for those recipients.
Speaking of recipients, we wrote a bit about online identity and the implications of unverified email addresses in regards to the Ashley Madison hack and cautioned about false data and what might result from the release of that data.
Steve’s in-depth technical series for August was a two-part look at TXT records — what they are and how to use them — and he explains that the ways people use these, properly and improperly, can have a real impact on your sends.
In spam news, the self-proclaimed Spam King Sanford Wallace is still spamming, despite numerous judgments against him and his most recent guilty plea this month. For anyone else still confused about spam, the FTC answered some questions on the topic. It’s a good intro or refresher to share with colleagues. We also wrote about the impact of botnets on the inbox (TL;DR version: not much. The bulk of the problem for end users continues to be people making poor marketing decisions.) In other fraud news, we wrote about a significant spearphishing case and how DMARC may or may not help companies protect themselves.

Do system administrators have too much power?

Yesterday, Laura brought a thread from last week to my attention, and the old-school ISP admin and mail geek in me felt the need to jump up and say something in response to Paul’s comment. My text here is all my own, and is based upon personal experience as well as those of my friends. That said, I’m not speaking on their behalf, either. 🙂
I found Paul’s use of the word ‘SysAdmin’ to be a mighty wide (and — in my experience — probably incorrect) brush to be painting with, particularly when referring to operations at ISPs with any significant number of mailboxes. My fundamental opposition to use of the term comes down to this: It’s no longer 1998.
The sort of rogue (or perhaps ‘maverick’) behavior to which you refer absolutely used to be a thing, back when a clean 56k dial-up connection was the stuff of dreams and any ISP that had gone through the trouble to figure out how to get past the 64k user limit in the UNIX password file was considered both large and technically competent. Outside of a few edge cases, I don’t know many system administrators these days who are able to (whether by policy or by access controls) — much less want to — make such unilateral deliverability decisions.
While specialization may be for insects, it’s also inevitable whenever a system grows past a certain point. When I started in the field, there were entire ISPs that were one-man shows (at least on the technical side). This simply doesn’t scale. Eventually, you start breaking things up into departments, then into services, then teams assigned to services, then parts of services assigned to teams, and back up the other side of the mountain, until you end up with a whole department whose job it is to run one component of one service.
For instance, let’s take inbound (just inbound) email. It’s not uncommon for a large ISP to have several technical teams responsible for the processing of mail being sent to their users:

Politics and Delivery

Last week I posted some deliverability advice for the DNC based on their acquisition of President Obama’s 2012 campaign database. Paul asked a question on that post that I think is worth some attention.

Deliverability advice to the DNC

I was working on another post for this afternoon, but when I checked Facebook Autumn Tyr-Salvia had posted a link that’s much more interesting to talk about.
It seems the Democratic National Committee has acquired President Obama’s email list from the 2012 campaign.