Anyone know why…

Countless questions about email troubleshooting start with “does anyone know why.” Unfortunately, most of these questions don’t contain enough detail to get a useful answer.

In the case of email, even the smallest redactions, like the IP address and the domain in question, can make it difficult for anyone to provide help. Details matter.
Every detail matters, sending IP and domain are just the beginning. Who’s doing the sending? What is their authentication setup? What IP are they using? How were the addresses collected? What is their frequency? What MTA is used? Are they linking to outside sites? Are they linking to outside services? Where are images hosted?  Is the mail going to the bulk folder or being rejected? What ISPs or filters are involved?
The relevant questions go on and on and on.
We send fairly detailed question lists to clients. I regularly look at them to try and make them shorter. But the reality is these are questions that are relevant. Without enough information we simply cannot troubleshoot delivery problems.
 

Related Posts

Troubleshooting and codes

Microsoft is still in the process of rolling out new mail servers. One thing that is new about these is some new codes on their error messages. This has led to questions and speculations as to what is going on.

Read More

Troubleshooting delivery is hard, but doable

Even for those of us who’ve been around for a while, and who have a lot of experience troubleshooting delivery problems things are getting harder. It used to be we could identify some thing about an email and if that thing was removed then the email would get to the inbox. Often this was a domain or a URL in the message that was triggering bulk foldering.
Filters aren’t so simple now. And we can’t just randomly send a list of URLs to a test account and discover which URL is causing the problem. Sure, one of the URLs could be the issue, but that’s typically in context with other things. It’s rare that I can identify the bad URLs sending mail through my own server these days.
There are also a lot more “hey, help” questions on some of the deliverability mailing lists. Most of these questions are sticky problems that don’t map well onto IP or domain reputation.
One of my long term clients recently had a bad mail that caused some warnings at Gmail.
We tried a couple of different things to try and isolate the problem, but never could discover what was triggering the warnings. Even more importantly, we weren’t getting the same results for identical tests done hours apart. After about 3 days, all the warnings went away and all their mail was back in the inbox.
It seemed that one mailing was really bad and resulted in a bad reputation, temporarily. But as the client fixed the problem and kept mailing their reputation recovered.
Deliverability troubleshooting is complicated and this flowchart sums up what it’s like.

Here at Word to the Wise, we get a lot of clients who have gone through the troubleshooting available through their ESPs and sometimes even other deliverability consultants. We get the tough cases that aren’t easy to figure out.
What we do is start from the beginning. First thing is to confirm that there aren’t technical problems, and generally we’ll find some minor problems that should be fixed, but aren’t enough to cause delivery problems. Then we look at the client’s data. How do they collect it? How do they maintain it? What are they doing that allows false addresses on their list?
Once we have a feel for their data processes, we move on to how do we fix those processes. What can we do to collect better, cleaner data in the future? How can we improve their processes so all their recipients tell the ISP that this is wanted mail?
The challenging part is what to do with existing data, but we work with clients individually to make sure that bad addresses are expunged and good addresses are kept.
Our solutions aren’t simple. They’re not easy. But for clients who listen to us and implement our recommendations it’s worth it. Their mail gets into the inbox and deliverability becomes a solved problem.

Read More

Where do you accept reports?

One of the things that is most frustrating to me about sending in spam reports is that many ESPs and senders don’t actively monitor their abuse address. A few months ago I talked about getting spam from Dell to multiple email addresses of mine.
What I didn’t talk about was how badly broken the ESP was in handling my complaint. The ESP was, like many ESPs, an organization that grew organically and also purchased several smaller ESPs over the course of a few years. This means they have at least 5 or 6 different domains.
The problem is, they don’t effectively monitor abuse@ for those different domains. In fact, it took me blogging about it to get any response from the ESP. Unfortunately, that initial response was “why didn’t you tell us about it?”
I pointed out I’d tried abuse@domain1, abuse@domain2, abuse@domain3, and abuse@domain4. Some of the addresses were in the mail headers, others were in the ESP record at abuse.net. Three of those addresses bounced with “no such user.” In other words, I’d tried to tell them, but they weren’t accepting reports in a way I could access.
Every ESP should have active abuse addresses at domains that show up in their mail. This means the bounce address domain should have an abuse address. The reverse DNS domain should have an abuse address. The d= domain should have an abuse address.
And those addresses should be monitored. In the Dell case, the ESP did have an active abuse@ address but it was handled by corporate. Corporate dropped the ball and never forwarded the complaint to the ESP reps who could act on the spam issue.
ESPs and all senders should have abuse@ addresses that are monitored. They should also be tested on a regular basis. In the above case, addresses that used to work were disabled during some upgrade or another. No one thought to test to see if they were working after the change.
You should also test your process. If you send in a complaint, how does it get handled? What happens? Do you even have a complaint handling process outside of “count and forward”?
All large scale senders should have appropriate abuse@ addresses that are monitored. If you don’t, well, you look like a spammer.

Read More