Recent Posts

Privacy policies in court

Venkat has an analysis of a case where an individual provided a unique address to a vendor and that vendor released the address in violation of the posted privacy policy. The federal court rejected the suit due to the failure of the plaintiff to provide evidence of harm.
I posted last week about privacy policies and how often they are intentionally or unintentionally violated and when email addresses leak. Courts have consistently ruled against plaintiffs. It seems that the courts believe merely revealing information, even in contradiction to a posted privacy policy, is not actionable by the plaintiff.
As a consumer, I really don’t like the ruling. If a company is going to post a privacy policy, then they should follow it and if they don’t, I should be able to hold them responsible for their lies. Back in the land of reality, I am not surprised at the rulings. Individuals have never owned their personal information, it is the property of the people who compile and sell data
It does mean, however, that privacy polices are not worth the paper they’re written on.

I have an email delivery problem. Can you help?

I see a lot of requests for help with some sort of delivery problem, sent to me as an individual, sent to Laura as part of a consulting relationship, sent to ISPs, sent to organizations running blacklists or sent to industry mailing lists, both public and private.
Some of them could be done better. OK, most of them could be done better, some of them could be done a lot better. Here’s some things to do to get the best response from your delivery consultant, your fellow mailing list members or your ISP contact.
Be specific about what delivery problem you’re seeing
Are you seeing SMTP hard rejections? Are you seeing slow delivery (due to soft rejections, or connection level timeouts)? Or is the mail being delivered, but ending up in the bulk folder?
Bad question and answer: “Is anyone seeing delivery problems with Yahoo?” leads to “There’s a ‘y’ in the month, of course we’re seeing delivery problems at Yahoo.”
Better question for a useful answer: “I started to see a lot more soft bounces from Yahoo last Thursday, and our probe accounts there are seeing mail ending up in the bulk folder – is anyone else seeing this?”
Describe the symptoms
One of the most important things is to describe the symptoms you’re seeing, rather than just your guess at what the underlying problem is.
Bad question: “Our client, the Breast Cancer Foundation, is seeing delivery problems because of the word ‘breast’ – how do we get them whitelisted?”
Better question: “Our client, the Breast Cancer Foundation, is getting filed in the junk folder at AOL – what should we look at to work out why?”
Mention where you’re getting your information
Are you seeing detailed rejections in your mail logs, or just seeing your outbound mail queues growing? Are you seeing bulk folder delivery on your own email accounts at the receiver, or are you relying on data from a commercial mailbox monitoring company?
Provide the basic information about delivery that’s usually going to be needed

What IP address are you sending email from? What domain are you sending to? Or, if you’re contacting the ISP, what email address? What sort of mail are you sending? (If you’re contacting a blacklist or ISP, include the IP address in the subject line).
Are you the only person sending email from that IP address, or is it shared by other users?
If you’re getting rejections, bounces or deferrals, include the rejection message or bounce message.
How much mail are you sending to the domain where you’re seeing a problem? How much is being rejected or delayed?
What, if anything, have you changed recently? If you’re mailing for yourself, did you just start mailing a new bunch of contacts you’ve acquired (or discovered, in an old database)? If you’re an ESP, is this a new customer, or have they been mailing successfully for a while?
What are your typical complaint / feedback loop rates? What are your typical user unknown or rejection rates? If you’re monitoring inbox delivery, what are your inbox rates at this receiving domain?
Do you have a feedback loop or whitelist set up with this receiving domain? Are you using any sort of authentication (SPF, DKIM)?
Bad question: “I’m seeing a lot of bounces from AOL. Any idea why?”
Better question: “I’ve been sending mail without any problems for a while, but most of my AOL recipients have been rejected today, with the message 554 HVU:B1 http://postmaster.info.aol.com/errors/554hvub1.html. We don’t have a feedback loop or whitelist with AOL. What happened?”
Say what you’ve already done
If there’s a URL in the rejection message, did you click on it? Did the page it led to help?
Did you contact the receiving ISP already? What did they say?
Timeliness – there’s no such thing as a delivery emergency
Email delivery problems are never a life-or-death issue. Don’t demand immediate responses to email. Don’t follow up with a phone call five minutes after sending the email.
Conversely, if you saw a delivery problem three weeks ago which has since fixed itself then not only does nobody care, it’s likely that some of the information that would have helped diagnose the problem may no longer exist.
Appropriate communication channel

It’s very difficult to resolve a delivery issue by ‘phone. Partly that’s because you need to communicate some detailed information (like IP addresses) where even a single typo can make any analysis worthless, so cutting and pasting is the only way to avoid problems. But it’s also partly because it’s often something that can require significant work to analyse (checking databases, delivery logs, reputation sources, email structure, checking with other people working in the field), all of which is difficult to do while also dealing with someone on the ‘phone.
Avoid using IM for this too, unless you’ve been asked to do so. And if you’re using IM, offer to send the bulkier data (logs, IP addresses, sample messages) by email.
If you’re communicating with someone where answering your questions is part of their job description it’s even more important to use email, so that all the information is stored in their ticketing system – both for future reference by them or their colleagues, and also to make sure that their work is visible to their employer.
Respond appropriately to questions
It’s likely that whoever you’re asking may need additional information, such as a sample message. If they ask you for more information, respond with it as soon as possible, while they still have the issue in their mind.
Don’t argue that the information is irrelevant, or they don’t need to know it. Really, they wouldn’t ask if they didn’t think it might be relevant. If you can’t provide it (because you don’t have it, or for privacy or contract reasons) explain that, and see if there’s something else that might provide the same useful information.
Respond appropriately to answers
You asked the question because you didn’t know the answer, and you thought the person or group you asked might. So rejecting an answer you get just because it seems wrong to you or you don’t fully understand it is probably a bad idea.
I regularly see clients who are paying good money for extremely competent deliverabilty advice refuse to accept the answer they’re given – insisting that the problems can’t possibly be due to the content of the email, or the reputation of the sending IP address, or the types of links included in the email. Then, after wasting several (billable) hours arguing with their consultant they actually try the change suggested, and it helps with the problem.
If you’re asking a mailing list, rather than an individual, then it’s possible you will get some completely useless suggestions. It’s still better to politely explain why you think they don’t apply (and listen to any replies you get to that) than to reject or ignore them out of hand.
Courtesy
You’re asking for help. Even if you’re paying the person you’re asking for advice you’re still more likely to get service above and beyond if you’re pleasant to deal with. Wrap a little social lubricant around your question – a “Hi!”, “When you get a moment, could you take a look at…”, “Thanks!” goes a long way.
Be respectful of their time. If it’s not an urgent issue, let them know that. Try not to ramble.
When the problem is resolved, write and thank them for their effort. If you identified the problem and it wasn’t what they thought, explain briefly what the issue was. You never stop learning, and it’s possible that knowing that will help them elsewhere.
Be nice. Be brief. If you’re easy to deal with, you’ll get more helpful responses.

Open rates

Right now, there is no way to compare open rates as everyone calculates them differently. Mark Brownlow covers this today.

The not April Fools post

I thought for a while about putting up an April Fools post, but decided against it. However, today being April first, anything I post is going to be treated suspiciously.
So I decided to ask my readers: what would you like to have me blog about over the next few months? What topics have I touched on that you’d like me to explore deeper? Is there something I’ve not discussed that you would like me to post on?
Also, what information would make your job easier? I know my ISP info chart was tweeted and heavily linked to, is there other information I could put together that would be similarly useful?

Supreme Court declines to hear anti-spam case

Yesterday the Supreme Court declined to hear an appeal for Virginia v. Jaynes. This means that the Virginia state supreme court ruling overturning the Virginia anti-spam law currently stands.
Jeremy Jaynes was a well known spammer who went under the name Gavin Stubberfield. He was pretty famous in anti-spammer circles for sending horse porn spam. In 2003 he was arrested under the Virginia state anti-spam statute. He was initially convicted but the conviction was overturned on appeal.
Ethan Ackerman has blogged about this case, including a recap today.
Venkat Balasubramani has also blogged about this case.
Mickey Chandler has the docs.
John Levine weighed in.
News Articles: CNN, Washington Post, CNET

Delivery can be counter-intuitive

We all know that receiving ISPs rate limit incoming email. With the volumes of mail that they’re currently dealing with they must do that in order to keep their servers from falling over.
A client was dealing with rate limits recently. These were not typical rate limits, in that the recipient ISP was 4xxing mail. Instead, the recipient ISP was not accepting any incoming connections. The client was having a bit of a difficult time understanding what was happening and why the problem wouldn’t be solved by increasing the rate at which they were trying to send to the ISP.
Imagine if you will, that at every ISP there is a reception desk that manages the incoming calls. The receptionist is under orders from the to limit the number of calls coming in. When the phone rings, the receptionist can do any of the following:
1) answer the phone and put the call through (250 message accepted)
2) answer the phone and put the caller on hold (connection hangs or delivery is slow)
3) answer the phone and tell the caller to call back later (4xx message deferred)
4) fail to answer the phone (no connection at all)
The delay the client was seeing was #4, in that they were attempting so many connections at once that the ISP was just not answering.
In this case, reducing the number of connections attempted worked. The “receptionist” was not so overwhelmed by the number of ringing lines that she was able to actually answer all the calls and put them right through.
While lowering the rate at which the client was attempting to delivery seems counter intuitive to getting improved delivery, because we understood the mechanism we could lower rate and get an increase in delivery.

Happy Friday

Mark Brownlow released a video earlier this week titled “If B2B marketing emails could talk.” Enjoy.

HT: Mickey

Fake privacy policies

I sign up at a lot of websites and liberally spray email addresses across the net. These signups are on behalf of one customer or another and each webform gets its own tagged and tracked email address. I always have a specific goal with each signup: getting a copy of a customer’s email, checking their signup process, auditing an affiliate on behalf of a customer or identifying where there might be a problem in a process. Because I have specific goals, I am pretty careful with these signups and usually uncheck every “share my email address” box I can find on the forms.
In every case the privacy policies of my clients and the things they tell me are explicit in that addresses will not be shared. It’s all opt-in, and email addresses are not shared without permission. Even in the cases where I am auditing affiliates, my clients assure me that if I follow this exact process my address will not be shared. Or so the affiliates have assured them.
Despite my care and the privacy policies on the websites, these addresses occasionally leak or are sold. This is actually very rare, and most of the websites I test never do anything with my address that I don’t expect. But in a couple cases these email addresses have ended up in the hands of some hard core spammers (hundreds of emails a day) and there was no useful tracking I could do. In other cases the volume has been lower, and I’ve watched the progression of my email addresses being bought and sold with morbid fascination.
Today an address I signed up at a website about a year ago got hit with multiple spams in a short time frame. All came from different IPs in the same /24. All had different domains with no websites. Whois showed all the domains were registered behind a privacy protection service. Interestingly, two of the domains used the same CAN SPAM address. The third had no CAN SPAM address at all. None of these addresses match the data I have on file related to the email signup.
It never ceases to amaze me how dishonest some address collection outfits. Their websites state clearly that addresses will not be bought an sold, and yet the addresses get lots of spam unrelated to the original signup. For those dishonest enough to do this they’ll never get caught unless recipients tags and tracks all their signups. Even worse, unless their partners test their signups or their mailing practices, the partners may end up unwittingly sending spam.

Email is store and forward

Many of us are so used to email appearing instantaneous, we forget that the underlying protocol was never designed for instant messaging. When the SMTP protocol was originally proposed it was designed to support servers that may have had intermittent connectivity. The protocol allowed for email to be spooled to disk and then sent when resources were available. In fact, almost everyone who was around more than 10 years ago knows of a case where an email took weeks, months or even years to deliver.
These days we’re spoiled. We expect the email we send to friends and relatives to show up in their mailbox within moments of sending it. We expect that sales receipt or e-ticket to show up in our mailbox within instants of a purchase. We expect that our ISPs will get us email immediately, if not sooner.
But there are a lot of things that can slow down email delivery. At several points in the process an email may be spooled to disk. It stays on the spool until the next part of the delivery process can happen. Other points of slowdown include the various anti-spam, anti-virus and anti-phishing protections that ISPs must implement. Then add in the extreme volume of email (around 10 billion messages a day) and all of a sudden email delivery is slower than many senders and recipients expect it to be. This delay is not ideal, but the system is designed so that mail is not silently discarded.
While individual emails may be delayed, most users will rarely see that delay in the email that they send. Bulk senders, who may be sending thousands or hundreds of thousands of emails a day, may see more delays in a single send than the average user sees in years of sending one-to-one email.
Email is store and forward, not instant. Sometimes that means there is a delay in getting email into the recipients inbox. And, sometimes there isn’t anything anyone can do to speed up delivery, except to adjust expectations of how email works.

Cox FBL update

Delivery mailing lists have been a buzz this week trying to figure out what is going on with the Cox FBL. Someone tried to sign up for the FBL and received a message saying Cox was no longer accepting applications. They forwarded the rejection to some of the mailing lists asking if anyone else had seen a similar message. Panic ensued. Rumors and futile suggestions flew wildly. OK, maybe that’s a slight exaggeration, but there did seem to be more than a little consternation and confusion about what was going on.
Everyone can stop panicking now.
Yes, Cox did stop accepting new applications for their FBL. They were swamped and overwhelmed with applications and had quite a significant backlog. One of my clients got caught in this backlog. I applied for them back in mid-October and they were just approved last week.
In order to solve the backlog problem, they shut down new applications. They will be working through the current applications and when they’ve approved all the current ones, they will start accepting new ones. I expect that it may be a couple months before they’re accepting applications again.
No need to panic. No need to email lots of people at Cox. No need to contact their FBL provider. Remain calm.
If you were lucky enough to get an application in, they will be getting to it as soon as possible. You will receive an email when you are approved.
If you have already been approved, there will be no interruption in your FBL. You will continue to receive reports during the signup hiatus.