Groklaw on the Spamhaus case

Here's an update from Groklaw on the lawsuit brought against Spamhaus by e360. Good reading, good insight. As always, the comments from the peanut gallery contain a lot of armchair lawyering, much of it suspect.

Who's been sued under CAN-SPAM?

I received the question yet again today: Who's been sued under CAN-SPAM? Let's take a look and see what our good friend, the Internet, has to say on the subject:

Ask Al: Help, my domain is being forged!

John from the UK writes: We have recently -- the last 2 weeks -- become victims of a spamming outfit. They have borrowed our domain name and are sending out emails from random fictitious addresses within the domain. We know about it because of the bounce back messages from corporate and ISP email servers. The emails are not being sent via our hardware and software. They are being sent from a large number of IP addresses, most probably falsified. Is there anything we can do to address this problem?

I asked around on John's behalf. What I heard back wasn't overly encouraging. The answers I got ranged from colorful variations on "too bad, welcome to the Internets" (I'd never heard the acronym "BOHICA" before) to "implement complicated technical solutions that kind of help, but not really."

The short answer here is that you don't have a ton of options other than just putting up with it. If the level rises to the point where it'd be appropriate for you to bring lawyers into the fray, I'd recommend finding a savvy internet consultant or anti-spam group to help you track down the offenders. I'm sure the spam is coming from hosts all around the Internet and I doubt that they correctly indicate who the sender is (both are clear violations of the US CAN-SPAM law). Spamhaus, the anti-spam group most well known, is especially adept at this type of thing. I don't know if they consult for folks in your situation, but it's worth investigating. Their website is at www.spamhaus.org.

In the realm of a technical solution, BATV (Bounce Address Tag Validation -- see http://mipassoc.org/batv/) is a process that a mail server can employ to help determine good bounces from bad.

Matt Sergeant of email security and management service provider MessageLabs was kind enough to explain to me how it works. Here's what he had to say:

Instead of sending MAIL FROM: your MTA (mail transfer agent) munges that into MAIL FROM: (the "cookie" part is usually based on the date, but it can get more complex than that). If you get a bounce back (MAIL FROM:<>) your MTA checks the RCPT TO -- If it's not RCPT TO: but instead to plain old then you know it was a forged mail, because all your outbound mail has the cookie attached.



It's very effective, but breaks any remote end system that keys off the MAIL FROM address (and there are lots of such systems, making a roll out on a large and diverse system problematic). Very effective on systems you have lots of control over though.

If that sounds a bit technical, that's because it is. It also doesn't stop the bad guys from doing what they're doing, it just helps you filter out the bounces more easily.

SpamAssassin offers a "Virus Bounce Toolset" which is supposed to help in a similar fashion.

Eventually, email authentication technologies like SPF (Sender Policy Framework) and DK (DomainKeys) could help with stuff like this. If you publish an SPF record, you're telling the world that your mail only comes from a certain set of IP addresses. The spammer's mail would not be coming from those specified IP addresses, and receiving ISPs could filter or reject the mail based on this fact. Look for this in the future, but it's not widely deployed or enforced currently.

Co-Registration Woes

In March 2005, I was helping a top-tier ISP with an issue related to a sender utilizing co-registration. The sender wasn't a client of my (then) employer, but the ISP had asked me to assist them with an issue. When you signed up on this sender's site, if you opted-in, your data was passed to a co-reg vendor for various other purposes. This process was supposed to be all double opt-in. It clearly wasn't. At various stages in testing the processes, I had given them unique addresses, so I could test the system without appearing to be a repeat visitor. I shared info with the ISP (who passed it on to the sender) on what process flaws I found. After some go arounds with everybody involved, address and consent verification was properly enabled. I called it a win and moved on to my next fire of the day.

Moving on to today, October, 2006. I'm looking through one of my big "spam" folders. I note that from August 31 to October 6, I've received 549 email solicitations to one of the addresses that was passed along to the co-reg vendor. That single email address has received 14 advertisements every day, for as far back as I have data handy. It suspect it goes back further, but I don't have any data to determine this.

I'm not looking very deeply at the messages themselves to see if they're CAN-SPAM compliant. They probably are. That's not really the issue. My focus here is more on the volume of messages being received: More than 500 in just about five and a half weeks. That's very excessive.

Think about it. If you're a savvy email marketer, you know about the concept of email frequency. How often you should mail your list. Smart strategists spend a lot of effort testing to determine what mailing frequency will get you the best click through and conversion response rate. But if you buy a co-reg list, you don't know who else is mailing it and how often. You can control your frequency, but you can't control everybody else's frequency. So you have no idea if the list is being burnt out through excessive mailing (as it clearly is in this case), or even if the other senders messages are appropriate and non-objectionable. Your mail becomes just one of the potentially many messages the people on the list are receiving. Are you sure these people are going to respond well? I'm not.

Just another data point on why buying co-reg lists from a list broker isn't that great of a practice.

Google Code Search

On Friday, NetworkWorld talked about Google's new "Code Search" tool:

"The company's new source-code search engine, unveiled Thursday as a tool to help simplify life for developers, can also be misused to search for software bugs, password information and even proprietary code that shouldn't have been posted to the Internet, security experts said Friday."

The best (or worst) part of this is that Google Code Search can also be used to harvest email addresses.

Uh oh.

Who has your personal information?

Be careful about giving your information out for sweepstakes.

I signed up for some sweepstakes hosted by Peel.com on May 6, 2003. Like I always do, I gave them a tagged (unique) address, so I could tell how my address was used (or misused) later. Flash forward a few years. I've since moved, and am not running my own mail server at the moment. I'm still getting tons of spam every day, and occasionally I want to search through it for various things, so I forward the spam into one of a couple different Gmail accounts. I check them periodically, weed out any non-spam with forwarding rules and so forth, and keep an eye out for anything that looks interesting.

Which brings us back to Peel.com. From September 20th thru October 8th, I've received 22 spams to the address I gave only to Peel.com. Personally identifiable information in the mails reinforces my belief that whoever is sending me this mail has access to all the information I gave out when signing up for this sweepstakes.

The messages do not identify themselves as a commercial advertisement, do not contain the postal address of the sender, and do not include a mechanism to opt-out. These are all clear violations of the US CAN-SPAM law. None of the company or companies behind the mail haven chosen to identify themselves. Each of the 22 messages has a different sender, a name of an individual, which I suspect is false.

Links in the messages seem to drive to various sites hosted on Geocities. I haven't clicked on the links to find the actual destinations.

The subject lines are a combination of the nonsensical and deceptive. Examples: "Bad info on your Experian Credit Score", "Shipment Info", "Superintendent was just suspended from work", "Credit score resolution submitted", et cetera. The source IPs are from the UK, Australia, China, and other places. I assume they're infected computers on broadband connections.

This is a perfect example of how NOT to handle customer or recipient data. I don't know if Peel.com is behind the sending of this mail, or if they are just list brokers that sell the captured data to whoever can afford to pay, or what. If this is a situation where Peel.com is feeding this data to a co-reg list broker, then we've got the perfect example of why you shouldn't ever buy a co-registration list, because the recipients on these lists are already probably receiving deceptive messages, and your messages are not likely to be any more warmly received.

Let's be clear. I don't even know who is sending these messages. All I know from the data I have in my inbox is that I'm getting spams to an address that I gave only to Peel.com, and it contains information that I reasonably believe that I gave only to Peel.com. I have no idea what happened to it from there, but whatever happened, there seems to be a connection between me submitting my personal information to a web form on Peel.com and me now receiving deceptive mail routed through computers overseas.

Spamhaus in the News

Here's a lawyer's take on the $11.7 million lawsuit and summary judgement against the UK anti-spam group Spamhaus.

If it's good enough for the cops...?

I was pleased to discover today that even the Chicago Police Department utilizes double opt-in for their newsletters signup. I wonder what led them to implement their signup form in this fashion? I've dropped them a line asking for more info, we'll see if they respond. If they do, I'll mention it here.

Sending an attachment with your email campaign?

It seems pretty basic, but I often get asked how to attach a file to an email campaign. Maybe it's just going to a handful of folks, but you don't always want the hassle of sending it to each person individually from Outlook. The problem is, you'll find that most email service providers decline to provide functionality that would allow you to embed or attach a file to your email message.

Security is the primary reason why. Thank the creators of viruses for screwing everything up for the rest of us. If you sent out any sort of big email attachment, nearly any corporate anti-virus/anti-spam filter is going to reject it, or remove the attachment. That's because there are so many different kinds of viruses and worms out there that try to propagate themselves via email. Those emails started out with simple attachments, trying to entice the gullible to click-to-open an attached application. As filtering evolved and that became harder, they eventually evolved to locking the virus payload up in a password-protected ZIP file, with instructions and password email written out in the body of the email message. You might think that people wouldn't be dumb enough to open something like that, but you'd be wrong. Actually, some of the deceptions are quite complicated. They look like emails from somebody you know, and you might even think that your friend is sending you something you want.

Even if the attachment doesn't get blocked, smarter recipients are wary of big attachments. Some will suspect the email is a virus delivery attempt. They'll question the email, ignore it, or report it as spam.

Also, email size is a concern. Big email messages can choke the recipient. That big attachment would take up a lot more space on the email servers between the sender and recipient. If the recipient was on a slow connection, it will take a lot longer for them to download the email message. They could be stuck downloading the attachment, even if they didn't want to. Not everybody has broadband yet, so you would not assume that your recipients can handle a giant-sized email.

Think of how HTML email messages work: When a legitimate email service provider serves a rich graphical email with HTML and images, they're not really sending all those images directly inside of the email. None of the images are actually embedded in the email. The HTML source code just links to them, usually back to the email service provider's website. If all the images were embedded, the email would be pretty large - but this way, the email itself is only a few kilobytes in size.

Do the same thing when you need to share a file with recipients on your list. Instead of attaching the file, link to it in your email. You do that by hosting it on a website, then pasting the link into your email message.

Don't have a website to host it on? Try Google Pages. This probably isn't the best way to share a file with hundreds of recipients, but if you're sharing it with just a few folks, it's very easy to set up. Creating a Google Pages account gives you a website at (your handle).googlepages.com, and you can upload and host files, and create webpages, up to a hundred megabytes worth. After you create a Google Pages account, just click on the "browse" button on the right hand side of the Google Pages screen. Locate your file and hit the "OK" button. It'll upload, and show up in your list of files along the right edge of the screen. You can copy and paste the shortcut to the link from that list, and drop it into your email message. Include that shortcut link in your email message, and recipients will be able to click on, or cut-and-paste, the URL, and they'll be able to download your file. It's pretty easy to do, and it works with just about any kind of file.