Perl Programmer/Consultant
Remote System Administrator
Free Software
... contact me
 
  while ($making_other_plans) { life(); }
  location('ipsstb', 'e-commerce', 'bulkmail', 'blacklisted_part_three');

 For Web Designers 2017-11-16 16:48:00 UTC Mail Delivery Problems? 

Thursday, August 16 2012

Blacklisted! Part Three

Wherein we think about ways to get your mailing lists clean and keep them clean.

First let us define the characteristics of a clean mailing list:

  • All recipients are confirmed opt-ins
  • All addresses are deliverable (valid domains, no bounces)
  • No addresses are spamtraps
  • No addresses are temporary, time-expiring addresses
  • All opt-ins have been reconfirmed by user action within the past year

If you've read Part Two then most of those are pretty obviously vitally necessary.

Those of my clients who've had the greatest problems with blacklisting are those who've employed downright lousy bulk mailing programs, and most of them were of the mindset that throwing mail at as many people as possible was the key to increased sales. It's not, but it seems plausible enough.

Crappy bulk mailing programs have been the bane of my career. How do I define "crappy" in this case? A crappy bulk mailer:

  1. Does not automatically unsubscribe undeliverable addresses that are detectable during the SMTP transaction
  2. Does not automatically unsubscribe undeliverable addresses that are detectable as bounces after message delivery
  3. Does not avoid attempting to send mail to invalid addresses, such as those that are in misspelled domains (e.g. "aol.cmo") or in domains that do not even exist
  4. Just dumps thousands of individual messages off on the system mail transfer agent (MTA, mail server, i.e. sendmail, Postfix) and leaves the scene of the crime
  5. Whether dumping messages off on the MTA or delivering itself, causes remote MTA's to suffer a "thundering herd" barrage of messages rather than a more respectful rate of delivery.

There's just no excuse for any bulk mailing software to behave in those ways. Sure, they'll get the mail out, for some definition of out, but they do more harm than good. By hitting on several or all five of those deficiencies they absolutely guarantee that customers who would otherwise have gladly bought from you this week never see your mail.

So, you've got a dirty list and a dirtier mailer. Now what? Well, for the time being, I'm going to suggest working around those things rather than uprooting them. A case history to illustrate:

I've a client who shall remain nameless whose list has historically been very dirty because their bulk mailer is a crappy one. It recently became important to address the matter and you can probably guess why. So I, the intrepid system administrator, did the following things over the course of a week or so:

  1. Implemented DKIM (DomainKeys Identified Mail) but not SPF.
  2. Caused the unsubscribe links in bulk messages to be placed near the top of the message and made prominent, leaving in place those that had always been near the bottom of the page and not so obvious
  3. Registered for every email abuse feedback loop I could find
  4. Wrote software to automatically process the email that would soon come flooding into the abuse@ addresses from those feedback loops
  5. Wrote more software that would periodically parse the mail server logs to find undeliverable addresses and automatically unsubscribe them. (This is a bit trickier than it sounds.)
  6. Wrote more software that would periodically trawl the mailing list seeking and destroying temporary, time-expiring addresses

All of this took place about two weeks ago, right around the first of August (2012). What happened?

Sender Score Initial Recovery

I had originally lobbied for the more drastic approach of doing all of those things plus silently unsubscribing all recipients who hadn't been seen (logging in to the web site, making purchases, etc.) in the past year. I believe that had we done that we might have cleared that magical hurdle of a Sender Score of 80 already. We may yet clear that hurdle, and maybe even before the month is out. My client's promotional mail might soon be landing more in inboxes than in bulk/spam folders, and that's when the campaigns will become appreciably effective.

Since this more sensible program was put in place, we've purged nearly 6,000 undeliverable addresses, approximately 15%, from a list that was originally over 40,000. The interesting thing: Removals due to complaints are a whopping 46, and voluntary unsubscribes are all of 121. Clearly, undeliverable addresses were the biggest problem we had. It was the mail no one could ever see that resulted in a Sender Score that was always below 20 and quite often in the single digits. We're still being blacklisted by Cloudmark within hours of initiating a bulk send so we're still hunting down undeliverables -- we can't know they're undeliverable while our connections are being refused due to blacklisting.

I believe that purging the list of users who've not been seen in the past year would solve the problem, but I'm not even trying to overcome the resistance to that bold move. In these matters I am a consultant only, so I am mindful of that fine line between tolerable and intolerable discomfort.

If you've got a crappy bulk mailer and would like some tools work around it, and are not averse to paying for them, we should talk about it. Later this year I'll be releasing my own bulk mailing software that will incorporate all of what I know about these things in its design. I've not yet settled on the marketing of it, whether or not to offer hosted plans, et cetera -- if you're interested and would like to provide some input on such matters, I'd love to hear from you.

In Part Four I'll address the fallacies that people cling to that keep them in spammer mode. Until then: Be well, fellow space travelers!

→ committed: 8/16/2012 15:17:00

[ / e-commerce / bulkmail] permanent link

Comments: 0    Trackbacks: 0

 

Comments are closed for this story.

 

Trackbacks are closed for this story.

Save the Net

Creative Commons License

Project Honeypot Member

 
August 2012
Mon Tue Wed Thu Fri Sat Sun
   
16
   

By Month:

By category:

Feeds:

Served to 54.221.136.62:39626 at 16:48:00 GMT on Saturday, December 16, 2017.

return(0.9774);