Dealing with ISPs when you are blocked

Here is some advice on dealing with ISPs over a blocking issue.

  1. Do know what IP is blocked if it is an IP based block.
  2. Do know what domain is blocked if it is domain based block.
  3. Do know what the rejection message is and have it handy.
  4. Do be polite.  Most of the ISPs get hundreds of contacts a day, many of which are decidedly impolite. If you are the polite one you’re much more likely to float to the top than if you are one of the thousand screamers.
  5. Do not make threats. There is nothing you can threaten that they have not been threatened with before.
  6. Do not lecture them about the law. It is unlikely you understand the legal issues better than they, and their lawyers, do
  7. Do respect everyone’s time. Arguing is not productive. Asking for information and clarification is productive.
  8. Do remeber that they’re extremely busy. The ISP does not need to hear about your business model – brevity is a virtue.
  9. Do not mention CAN SPAM. That’s like saying “I do the bare minimum the law requires and expect you to accept my mail anyway.”
  10. Do not ask them to remove the block. Ask them what you did to get blocked and how to avoid being blocked in the future.
  11. Do remember this is probably the same person you will need to deal with in the future and that this is not a one time conversation. Leave them remembering you, if not fondly, at least productively.

The above all go for talking to the major blacklists, too.
Edited to add: 12. Do use the proper channels to contact them. 

Related Posts

Affiliates: what is a company's responsibility

Many of my clients come to me when they end up with delivery problems due to the actions of affiliates. These can either be listings in some of the URL blocklists (either public or private) or escalations of IP based listings. In many of the cases I have dealt with affiliates, the affiliates have sloppy mailing practices or are out and out spammers.
Recently the FTC settled with Cyberheat over their liability for the behaviour of their affiliates. In this settlement Cyberheat is required to monitor their affiliates as follows:

Read More

FBLs, complaints and unsubscribes

On one of my mailing lists there was a long discussion about the Q Interactive survey. Some of the senders on the list were complaining that unless ISPs provide FBLs they should not use complaints to make filtering decisions. The sender perspective is that it isn’t fair for the ISPs to have data and use it without sharing it back so that the senders could remove complainers.
This deeply, deeply misses the point.
The ISPs are in the business of keeping their users happy. Part of that is measuring how users react to mail. This includes providing “report spam” or similar buttons when they control the interface. Some ISPs have chosen to share that data back with senders. Some ISPs have made the choice not to share that information back.
But even the ISPs that share FBL data with senders do not expect that the only thing a sender will do is remove the email address. ISPs expect senders to actually pay attention, to not send mail that their recipients do not want. They expect that ESPs are going to notice that one customer has consistently high complaint rates and actually force their customer to stop sending mail that recipients think is spam.
Senders should keep track of complaint rates. Measure them per send. Do not waste time whining that this ISP or that ISP will not set you up with a FBL. Take the data from those ISPs that do have FBLs and measure it. It is extremely unlikely that a mailing will have grossly different complaint rates between ISPs. You have all the data you need in order to evaluate how your recipients are perceiving your email.
ESPs and senders who think that their only response to FBL complaints should be to remove that email are the ones most likely to have filtering and blocking problems. The ISPs are giving them valuable data that they can use to evaluate how their emails are being received. Instead of being ungrateful, wagging fingers and blaming the ISPs for not giving them the data they want, senders should spend more time focusing on what they can discover from the data that is shared with them.
A FBL email is more than an unsubscribe request, senders should stop focusing on the unsubscribe portion of the FBL process and focus more on the recipient feedback portion of it. What can you learn about your mail from a FBL?

Read More

Why does everyone tell you to avoid .biz in your emails?

… or Why do spam filters sometimes have some very strange ideas?
It’s been dogma for a long time that if you’re doing email marketing you should avoid using a .biz domain in your mails. Even if your main website was in .biz, you should use something different in your messages, perhaps a website you buy solely for use in email that redirects to your real .biz website. Last year I looked at why that was, and what could be done about it.
One main reason for avoiding it has been resolved (so if you’ve been avoiding using .biz URLs in your mail now might be a good time to re-test that decision). And enough time has gone by that I can share the ugly reasons as to why .biz was considered a sure sign of spam without good reason for so long without upsetting everyone.
The simple reason was SpamAssassin. SpamAssassin is very widely used to filter mail, both in it’s open source version and buried anonymously deep inside countless commercial spam filters and filtering appliances. Not only that, but SpamAssassin is readily available, so most people looking to do pre-mailing content checks or looking at why content-based filters are objecting to a particular email will use SpamAssassin as their model. It’s very widely deployed, and influential far beyond the size of it’s deployed base.
SpamAssassin is a score-based spam filter – it checks an email against hundreds of rules, adds up the scores of each rule that matches and, in typical setups, decides the mail is spam if the total score is five or more. Pretty reasonable, but here are a few of the rules and scores (from the 2006 version of SpamAssassin)

Read More