Script
5 steps for addressing deliverability issues
Following on from my reading between the lines post I want to talk a little bit about using the channels. From my perspective the right way to deal with 99% of issues is through the front door.
Last week I found myself talking to multiple folks in multiple fora (emailgeeks slack channel, mailop, IRC) about how to resolve blocking issues or questions. All too often, folks come into these spaces and start by asking “does anyone know someone at…” Fundamentally, that’s the wrong first question. Even if the answer is yes. It’s even the wrong question if a representative of the company is on the list where you’re asking for help.
If that’s the wrong question, what is the right question? Where can we start to get help with issues when we’re stuck trying to fix a delivery problem we don’t understand?
Who leaked my address, and when?
Providing tagged email addresses to vendors is fascinating, and at the same time disturbing. It lets me track what a particular email address is used for, but also to see where and when they’ve leaked to spammers.
I’d really like to know who leaked an email address, and when.
All my inbound mail is sorted into “spam” and “not-spam” by a combination of SpamAssassin, some static sieve rules and a learning spam filter in my mail client. That makes it fairly easy for me to look at my “recent spam”. That’s a huge amount of data, though, something like 40,000 pieces of spam a month.
Finding the needle of interesting data in that haystack is going to take some automation. As I’ve mentioned before you can do quite a lot of useful work with a mix of some little perl scripts and some commandline tools.
I’m interested in the first time a tagged address started receiving spam, so I start off with a perl script that will take a directory full of emails, one per file, find the ones that were sent to a tagged address and print out that address and the time I received the email. I can’t rely on the Date: header, as that’s under the control of the spammer, and often bogus. But I can rely on the timestamp my server adds when it receives the email – and it records that in the first Received: header in the message.
Palpable ennui
Put any group of senders together and the conversation invariably turns to discussions of how to get email delivered to the Inbox. There is an underlying flavor to most of these conversations that is quite sad. Many senders seem to believe that the delivery of their email is outside of their control and that since the ISPs are difficult to reach that senders are stuck. The ennui is palpable.
I am here to tell you that nothing could be further from the truth!
Senders are not passive victims of the evil ISPs. In 99% of cases, delivery problems are fully under the control of the sender.
Mail being deferred? Mail being blocked? Mail being delivered to the bulk folder? Senders do NOT NEED TO CALL THE ISP to fix most of these. Tickets do not need to be opened nor do personal contacts need to be employed. You can resolve the vast majority of problems with data you already have.
Personal Contacts at ISPs: Part 2
I’ve talked quite a bit recently about working with ISPs and personal contacts. Today I have an example of what not to do.
One of my ISP friends informed me that another blogger published correspondence from an individual at that ISP, including the individual’s full contact information. The correspondence wasn’t a big deal, the blogger was assigned an IP address by their ISP that was previously used by a spammer. The ISP had a block on the address and he was contacting them to get the block removed. It was totally a misunderstanding on the blogger’s part and the blogger removed the info when the ISP contacted him. Still, once something is out on the net, it’s out there forever.
Don’t do that. Really. When someone at an ISP helps you, don’t go publishing their information on a blog somewhere. They will find out, even if it’s just because their mailbox explodes or their phone starts ringing off the hook with multiple calls about an “emergency” situation. It hurts the person who helped you, who now has to deal with a major increase in volume and work load, and they’re never going to help you again.
This also hurts the rest of us, as ISP employees retreat farther and farther away from contact with senders. Even those of us who are careful with contact information may find it hard to get responses when others in the field are spreading info around.
I know some ISPs can be difficult to get any information from. That’s part of my reason for publishing the ISP information page was to help people find the right contact information. I think it’s extremely important for delivery professionals to understand that you don’t need a personal contact at an ISP to resolve most issues. What you do need is a deep understanding of SMTP, a smattering of knowledge about DNS and HTTP, a firm grasp of privacy issues and an understanding of the dynamics of email.
Personal contacts at ISPs
A lot of senders seem to think that the secret to good delivery is having personal contacts at the ISPs. That way, when there is a delivery problem you can call up your friend at the ISP and inform them that they have made a mistake. In this little sender fantasy world, the ISP rep then apologizes profusely, unblocks the sender’s mail and perform magic to prevent a block from ever happening again.
Like many fantasies, it doesn’t usually happen that way.
The big ISPs are moving more and more to automated systems that prevent individual employees from interfering. This isn’t actually anything new. I was at a party once and sharing a drink with a representative of one of the big three ISPs. We were talking about a delivery problem one of my clients was having. The rep told me that the ISP did not have any way to actually whitelist around the filter that this client was getting trapped in. The reputation based filtering systems that some ISPs are building are much more performance based and will probably result in those ISPs who can make exceptions now not being able to do so in the future.
When looking for a good delivery person, the real question senders should be asking relate to the skills of the people doing the troubleshooting not who do they know. Does the delivery person have experience troubleshooting delivery? Can they actually resolve problems without having to rely on information from the ISPs? Given the response times at many ISPs, even for personal contacts, it’s often faster to listen to your delivery person than find the ISP rep who will apologize for the mistake.
When the script doesn't work
DJ asks in the comments of Friday’s post:
As Seth said, great reminder. For those that have great processes/channels in place, I’ve found incredible success. However, sometimes I’ve found my answer on Twitter (i.e., @godaddyguy). Also, there have been times where I’ve gone through the script (i.e., shaw.ca) and have never heard back. What then?
Read More
Following the script
Yesterday I talked about breaking through the script in order to escalate an issue. I briefly mentioned that I always start out following the script and using the channels ISPs have provided. There are a number of reasons to do this all of which benefit you, the sender.
First off, when you use the designated communication pathway at an ISP there is a record of your contact. There are procedures in place to make sure your communication is addressed and you get a response. When you’re escalating to an individual, you’re using their communication channel. IMs get lost, email ends up buried in the pile, other things come up and a week later you’re still waiting for your answer.
Secondly, when you use the designated communication pathway at an ISP your contact is logged and tracked. This means that if the person you’re used to dealing with gets another job, moves on or otherwise isn’t able to communicate with you any longer you have a history with that ISP. The next person to move into the position and deal with issues can see that you’re a legitimate sender with a history of dealing fairly and professionally with ISPs.
Thirdly, handling direct and personal escalations are often outside the official job description the people directly contacted. This means that when they come up for review, the work they’re doing for people who won’t use channels is not as important as the other work they do. Sure, they may get some credit for helping people with problems, but they may not get the review they should get. This hurts not just the senders who believe they shouldn’t have to follow channels but also those of us who do follow channels, particularly in the current business climate. Do you really want to lose that awesome person you use because some dork thought they were too good, too important to use the provided form and that awesome person lost their job because they didn’t meet their official work goals?
Fourth, you’re not the only one escalating. I had the opportunity to visit my friend Anna from AOL a few years ago. One morning both of us had to actually get some work done, so we were parked in her living room on laptops. I was astonished at the number of IM windows she was juggling constantly. We’re talking 20 – 30 separate windows open at once, many of them troubleshooting sender issues. After seeing that I do as much as possible through the official channels that AOL has provided. She is my friend, and a very good one, and I still avoid using her as a contact point unless there is some emergency.
Remember this next time you are searching for that email address of the person from that ISP that’s currently blocking your mail. Use the official communication channels where possible, and always use them first. Using back channels for issues where the intended workflow works causes a lot of overhead and doesn’t scale at all well.
Breaking through the script
In handling day to day issues I use the ISP designated channels. This means I frequently get dragged into long conversations with people, probably outsourced to the far east, who can do nothing beyond send me a boilerplate.
This can be a frustrating experience when the issue you’re trying to deal with is not handled by the script. Generally, by the time someone has come to me for help, they are “off script” and I do need to actually talk to a human to get resolution.
With Hotmail, I’ve found that persistent repeating of very simple phrases will eventually get the issue kicked up to someone who can respond with something beyond another boilerplate. This can take days, but it is possible.
I’ve recently run into a Yahoo issue where I am trying to punch through the script, but have so far been unable to.
One of the services Word to the Wise offers is whitelisting. I collect info from customers, verify that what they’re doing will get them whitelisted at the ISPs that offer it, and then submit the information to the ISPs. Yahoo has recently moved to an online submission form for their whitelisting process, which is great for me. No more creating a giant document and then cutting and pasting the document into an email and then mailing it off.
The problem is, there seems to be a minor problem with the Yahoo Whitelisting submission form. When submitting an online application to Yahoo, they respond with a message that says “this application is not complete.”
I’ve been attempting to break through the script in order to find out what about the application is not complete. The webform has data checking, and you cannot submit a form while leaving any of the questions blank. Asking “what is wrong” when the application is kicked back has resulted in me having multiple copies of the whitelisting submission form.
It’s gotten so frustrating that I’ve escalated to personal contacts, but they can’t explain what’s not complete about the application as submitted online, either.
Has anyone had any success breaking through the Yahoo script? Has anyone managed to get IP addresses whitelisted through Yahoo using the online form?