Recent Posts

Who can you trust?

I’ve been recently dealing with a client who is looking at implementing authentication on their domains. He’s done a lot of background research into the schemes and has a relatively firm grasp on the issue. At this point we’re working out what policies he wants to set and how to correctly implement those policies.
His questions were well informed for the most part. A few of them were completely out of left field, so I asked him for some of his references. One of those references was the EEC Email Authentication Whitepaper.
My client was doing the best he could to inform himself and relies on industry groups like the EEC to provide him with accurate information. In this case, their information was incomplete and incorrect.
We all have our perspectives and biases (yes, even me!) but there are objective facts that can be independently verified. For instance, the EEC Authentication whitepaper claimed that Yahoo requires DKIM signing for access to their whitelist program. This is incorrect, a sender does not have to sign with DKIM in order to apply for the Yahoo whitelist program. A bulk sender does have to sign with DKIM for a Y! FBL, but ISPs are given access to an IP based FBL by Yahoo. I am shocked that none of the experts that contributed to the document caught that error.
Independent verification is one reason I publish the Delivery Wiki. It’s a resource for everyone and a way to share my knowledge and thought processes. But other experts can “check my work” as it were and provide corrections if my information is outdated or faulty. All too often, senders end up blaming delivery problems on evil spirits, or using “dear” in the subject line or using too much pink in the design.
Delivery isn’t that esoteric or difficult if you have a clear understanding of the policy and technical decisions at a range of ESPs and ISPs, the history and reasoning behind those decisions, and enough experience to predict the implications when they collide.
Many senders do face delivery challenges and there is considerable demand for delivery experts to provide delivery facts. That niche has been filled by a mix of people, of all levels of experience, expertise and technical knowledge, leading to the difficult task of working out which of those “experts” are experts, and which of those “facts” are facts.

Delivery Monitor Closing Down

Delivery Monitor by Aweber is one of the inbox monitoring services available for senders. Aweber has been in the process of winding down Delivery Monitor for the last few months and they will be turning the service off completely tomorrow.
A lot of folks have asked me about replacements for Delivery Monitor. There are, of course, Return Path and Pivotal Veracity, but many of the smaller mailers I talk to can’t justify the expenditure for either service.
Enter Green Arrow Monitor, a service provided by Green Arrow. This is a new seed list service aimed at marketers that need some delivery monitoring at commercial US ISPs. They’re reaching for the middle of the market. As a bonus, they’re offering special pricing for former Delivery Monitor customers.
While they don’t offer all the bells and whistles of other seedbox services, for the small to mid-size company that wants to know what their delivery is like at the major commercial ISPs this is a worthwhile service to investigate.
Full disclosure – I worked with GreenArrow to look at what parts of the market were being missed by other monitoring services and provide delivery consulting for some of their customers.

How to disable a domain

Sometimes you might want to make it clear that a domain isn’t valid for email.
Perhaps it’s a domain or subdomain that’s just used for infrastructure, perhaps it’s a brand-specific domain you’re only using for a website. Or perhaps you’re a target for phishing and you’ve acquired some lookalike domains, either pre-emptively or after enforcement action against a phisher, and you want to make clear that the domain isn’t legitimate for email.
There are several things to check before disabling email.
1. Are you receiving email at the domain? Is anyone else?
Check the MX records for the domain, using “host -t mx example.com” from a unix commandline, or using an online DNS tool such as xnnd.com.
If they’re pointing at a mailserver you control, check to see where that mail goes. Has anything been sent there recently?
If they’re pointing at a mailserver that isn’t yours, try and find out why.
If there are no MX records, but there is an A record for the domain then mail will be delivered there instead. Check whether that machine receives email for the domain and, if so, what it does with it.
Try sending mail to postmaster@ the domain, for instance postmaster@example.com. If you don’t get a bounce within a few minutes then that mail may be being delivered somewhere.
2. Are you sending email from the domain? Is anyone else?
You’re more likely to know whether you’re sending mail using the domain, but there’s a special case that many people forget. If there’s a server that has as it’s hostname the domain you’re trying to shut down then any system software running no that server – monitoring software, security alerts, output from cron and so on – is probably using that hostname to send mail. If so, fix that before you go any further.
3. Will you need mail sent to that domain for retrieving passwords?
If there are any services that might have been set up using an email address at the domain then you might need a working email address there to retrieve lost passwords. Having to set email back up for the domain in the future to recover a password is time consuming and annoying.
The domain registration for the domain itself is a common case, but if there’s any dns or web hosting being used for the domain, check the contact information being used there.
4. How will people contact you about the domain?
Even if you’re not using the domain for email it’s quite possible that someone may need to contact you about the domain, and odds are good they’ll want to use email. Make sure that the domain registration includes valid contact information that identifies you as the owner and allows people to contact you easily.
If you’re hosting web content using the domain, make sure there’s some way to contact you listed there. If you’re not, consider putting a minimal webpage there explaining the ownership, with a link to your main corporate website.
5. Disabling email
The easiest way to disable email for a domain is to add three DNS records for the domain. In bind format, they look like:

Confirming spam reports

Someone floated the idea of having ISPs confirm that a user really wants to report a mail as spam every time they do so. The original poster was asking for comments and what we thought of such an idea.

CAN SPAM Plaintiff ordered to pay 800K in lawyer fees

Asis Internet service has been ordered to pay over $800,000 in lawyer fees to Optin Global. Venkat has details. This is the same company that was recently awarded $2.5M judgment in a different case.

The importance of data hygiene

Over the weekend, one of the major ISPs purged a lot of abandoned accounts from their system. This has resulted in a massive increase in 550 user unknown bounces at that ISP. This ISP is one of those that uses bounces to feed into their reputation system and the purge may cause otherwise good senders to be blocked temporarily.
Talking to clients and other industry folks, it looks like the addresses that have newly bounced off had zero activity for at least 6 months. Nothing. Nada. No clicks. No opens. No interaction.
This is why data hygiene is so critical. Just because the emails are being accepted at the ISP, and even showing inbox placement at the mailbox monitoring companies does not mean that there is actually someone reading your email. Failure to look at overall data means that when an ISP bulk deletes abandoned accounts then bounces will increase. While I don’t expect this to have any real, long term effect on sender reputation I do expect that some senders with a lot of cruft on their list will see some short term delivery problems.
Companies that run re-engagement campaigns saw a whole lot less bouncing and even less blocking as a result of the purge. They were removing addresses that were non-responsive all along and thus didn’t have major deadwood on their list.
Ongoing data hygiene shows you what your list really is, not your list plus abandoned accounts. The addresses that the ISP purged? They were not valuable anyway. No one was reading that mail for at least 6 months.
If you did see a spike in bounces this weekend at a major ISP, you should really look at engagement. If some percentage of recipients at one ISP are actually non-existent, then it’s likely that about that same number are non-existent at other major ISPs as well. What are you going to do to identify and remove those dead addresses from your lists?

Spamtraps

There is a lot of mythology surrounding spamtraps, what they are, what they mean, how they’re used and how they get on lists.
Spamtraps are very simply unused addresses that receive spam. They come from a number of places, but the most common spamtraps can be classified in a few ways.

Email lost a valuable voice

In very sad news ClickZ announced today that Stefan Pollard, email marketer at Responsys and writer for ClickZ passed away recently. Stefan and I interacted over the years but we never had the opportunity to meet in person. His articles on email and delivery were always on my must read list. While I didn’t agree with everything he wrote, I always appreciated his writing and his point of view.
ClickZ is running an online memorial for Stefan which also links to a scholarship fund for his children run by Responsys.

Delivery problems are not all spam related

Not every delivery failure is due to poor reputation or spam. Sometimes ISPs just have problems on their mailservers and so mail doesn’t get through. It’s often hard for delivery experts (and their bosses and their customers and their clients) to watch email delays or rejections without being able to do anything about it.
Sometimes, though, there is nothing to do. The rejections are because something broke at the ISP and they have to sort through it. Just this week there’s been a lot of twitter traffic about problems at a major cable company. They are rate limiting senders with very good reputations. They have admitted there is a problem, but they don’t have a fix or an ETA. From what I’ve heard it they’re working with their hardware vendor to fix the problem.
Hardware breaks and backhoes eat fiber. Yes, ISPs should (and all of the large ones do) have backups and redundancies. But those backups and redundancies can’t always handle the firehose worth of mail coming to the ISPs. As a result, the ISPs start rejecting some percentage of mail from everyone. Yahoo even has a specific error message to distinguish between “we’re blocking just you” from “we’re shedding load and temp failing everyone.”

Public reputation data

IP based reputation is a measure of the quality of the mail coming from a particular IP address. Because of how reputation data is collected and evaluated it is difficult for third parties to provide a reputation score for a particular IP address. The data has to be collected in real time, or as close to real time as possible. Reputation is also very specific to the source of the data. I have seen cases where a client has a high reputation at one ISP and a low reputation at another.
All this means is that there are a limited number of public sources of reputation data. Some ISPs provide ways that senders can check reputation at that ISP. But if a sender wants to check a broader reputation across multiple ISPs where can they go?
There are multiple public sources of data that I use to check reputation of client IP addresses.
Blocklists provide negative reputation data for IP addresses and domain names. There are a wide range of blocklists with differing listing criteria and different levels of trust in the industry. Generally the more widely used a list the more accurate and relevant it is. Generally I check the Spamhaus lists and URIBL/SURBL when investigating a client. I find these lists are good sources for discovering real issues or problems.
For an overall view into the reputation of an IP address, both positive and negative, I check with senderbase.org provided by Ironport and senderscore.org provided by ReturnPath.
All reputation sources have limitations. The primary limitation is they are only as good as their source data, and their source data is kept confidential. Another major limitation is reputation sources are only as good as the reputation of the maintainer. If the maintainer doesn’t behave with integrity then there is no reason for me to trust their data.
I use a number of criteria to evaluate reputation providers.