Recent Posts

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.

Read More

ISP Postmaster Pages

I’ve been working on some reference information about ISPs for my own internal use as well as sharing with clients. There doesn’t seem to be any public reference site for postmaster sites, so I decided to publish what I’ve collected.

Read More

Can I use a purchased list?

Can I use a purchased list?
Thanks to the MailChimp folks for the great resource!

Read More

Landing pages

One thing I don’t talk about very much is what to do after mail has successfully been delivered to the inbox and the recipient has clicked on a link. Bronto Blog has a post from Friday with tips for successful landing pages.

Read More

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.

Read More

Better Preheaders

Mark Brownlow has an article about using pre-header space better in your emails.

Read More

Lycos Europe shuts down

Multiple bloggers have commented on Lycos Europe shutting down. Some of them have linked to domains involved. One person, who wishes to remain anonymous, has sent me a list of domains which have a MX pointing at Lycos Europe. If you see a failure to resolve or connect to any of these domains in the coming weeks, you should remove all the email addresses at that domain from your lists. The list is about 500 domains, so they’re behind a cut.

Read More

Yahoo FBL returns

This morning ReturnPath and Yahoo announced the new Yahoo FBL has gone live. Signups are being accepted at http://feedbackloop.yahoo.net/. Yahoo provides the following instructions:
Yahoo! offers a Complaint Feedback Loop service, free of charge, via this site operated by Return Path. To begin the process:

Read More

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.

Read More
Categories
Tags