Third party post-purchase research emails: spam?

My wife and I were lucky enough to be able to purchase a new car earlier this year. It's a nice car and we love it. But ever since then, seemingly once a month or so, I get a survey request related to automobiles and the automotive industry. Some from known entities, some from unknown entities. A number of them are coming from third parties that I didn't specifically hand my email address to.

The anti-spammer in me tells me that these emails are spam. Somebody I don't recognize is sending me list mail or bulk mail, to an address that I did not give to them.

But when talking with clients or potential clients I have had a lot of them try to tell me that this kind of mail is expected and that it's not spam.

For the moment, forget about who's right or wrong here.

Consider this: Just about all of those surveys have gone to my Gmail spam folder, including the most recent one. Why? Poor sender reputation, I think. Why? I would guess that perhaps I am not the only one questioning why I'm receiving mail from somebody I didn't give my email address to. I didn't report this mail as spam, but it sure looks like enough other people are reporting this sender's mail as spam and thus, making it near impossible for them to reliably get to the inbox.

That's the practical consideration. Not whether or not you think what you're doing is legal or expected or common or necessary; what recipients think is given greater weight. Enough weight that it can bog down your sender reputation.

That's why a mail stream or marketing program or survey program probably just doesn't work without clear cut permission. Regardless of what you think is right or wrong, your opinion (and my opinion) is only a tiny part of the equation.

Now Hiring: Word to the Wise

It sounds like consultancy Word to the Wise is growing! Laura Atkins is looking to hire a Deliverability Specialist to "perform technical investigation into client email systems, reviews messages sent by clients, and make recommendations based on analysis of the client’s email programs." Interested? Click here to learn more.

Is a wireless domain?

First published in 2005, the FCC's Wireless Domains list was intended to be a list of domains associated with mobile devices (cell phones, pagers, etc.) and that senders of commercial messages were to avoid those messages unless appropriate consent was obtained for each recipient. It sounds like a simple "don't spam me" list, but the form of consent referenced "must include the subscriber’s signature, which may be in digital or electronic form as allowed under the federal E-Sign Act and state counterparts" and the FCC has said that the burden of proof to resolve any complaint rests squarely on the sender, so the net was that most email service providers prohibited their clients from sending to those domains, unless the client implements verifiable consent compatible with the E-Sign Act or similar. (A longer discussion on what constitutes appropriate consent might make sense here but I don't have the time to dive deep and my focus today is more on the domain landing on the list, see below.)

Email industry insiders noted that the domain had landed on the FCC wireless domains list sometime in the past few days, meaning that if this procedure were to be followed, email services providers would have thirty days at max before they would be forced to restrict their clients from sending mail to subscribers at Yahoo Mail's primary domain name.

That's potentially a big deal! Thankfully, it seems to be recognized as an error and is being addressed. I know that both the FCC and Yahoo have been notified of this and my understanding is that it is likely to be resolved very soon, meaning that it probably won't be necessary for a bunch of senders to suddenly stop sending mail to their subscribers. Whew!

(Update: has been removed from the FCC Wireless Domains list.)

Interesting SBLs is back

Ever seen the @InterestingSBLs twitter account? It's kind of interesting and occasionally entertaining. It highlights various SBL entries that its anonymous author finds "interesting" by whatever criteria that may be. Because it's an ESP? An ESP's client? A Fortune 500 company? Not sure, but all have appeared there. My own employer has occasionally been called out on it, as have others. Some representatives of some companies have gotten really upset over being mentioned by that Twitter account, but not me. To me, it's really just a synopsis of a public record. And good companies occasionally have Spamhaus issues, too-- not just bad companies. It tells me it's something "interesting" to go look at, not that so-and-so is a scumbag spammer. If you or your company gets mentioned there, take a deep breath and look into it.

There are often big gaps between when @InterestingSBLs posts, but he or she seems to have been active as recently as just over a week ago.

If that doesn't interest you, there's always the Spamhaus SBL "Latest Entries" page, showing you what has been recently entered or recently removed into Spamhaus's main blacklist. This can be pretty interesting. I once knew an alleged spammer who spent most of his day hitting "refresh" on this page every few minutes, looking to find that partners in (alleged) crime may have been caught in the Spamhaus cross hairs.

Keep in mind that all Spamhaus SBL entries are effectively public information. Spamhaus does not password protect or otherwise obviously restrict access to the listing information available on their website. (I'm not necessarily making a case for whether or not they should be public or not, just noting how it is today.)

Purchased lists? DOA.

MailChimp's John Foreman explains the usual reasons why sending to purchased lists is a bad idea, but then he adds on one important practical fact: They perform very poorly. Click on over to the MailChimp blog to learn more.

Pre-order Spam Nation by Brian Krebs

From Brian Krebs: "The backdrop of the story is a long-running turf war between two of the largest sponsors of spam. A true-crime tale of political corruption and ill-fated alliances, tragedy, murder and betrayal, this book explains how the conditions that gave rise to this pernicious industry still remain and are grooming a new class of cybercriminals.

But Spam Nation isn’t just about junk email; most of the entrepreneurs building and managing large-scale spam operations are involved in virtually every aspect of cybercrime for which there is a classification, including malware development, denial-of-service attacks, identity theft, credit card fraud, money laundering, commercial data breaches and extortion."

I'll be ordering my copy soon!

Does Gmail use Spamhaus blacklists?

Probably, implies Return Path based on a correlation between a typical Spamhaus blacklisting and drop in inbox delivery rates at Gmail. I think it's safe to assume that Google does use Spamhaus data for some sort of reputation calculation impacting Gmail deliverability.

Ask Al: Should I add a DMARC record to fix the Yahoo issue?

A friendly representative of a company who helps small businesses sell products asked: "We're having problems forwarding mail from our customers back to our users due to the new Yahoo and AOL restrictive DMARC policy. If we add a DMARC record for our own domain name, would that help address the Yahoo/AOL bouncing issue? Would that explain to the ISPs that we're not spoofing when we forward on that mail?"

No, this wouldn't fix your issue. It's probably not a bad idea for you to implement a DMARC record for your domain, especially if the domain is one you use for email marketing or online retail and want to make it harder for bad guys to spoof it. (But be sure you learn more about DMARC before proceeding; I would recommend partnering with somebody like Return Path or Agari to use their tools and benefit from their expertise with regard to anti-phishing/spoofing and DMARC.)

The reason this wouldn't fix your issue is because the Yahoo and AOL DMARC policies affect only mail that has a Yahoo or AOL domain in the from address. Also, they have the potential to affect all/any mail with a Yahoo or AOL domain in the from address. What other domain you might have in the message or message headers has no bearing on that fact. Whatever DMARC policy setting you publish wouldn't override whatever policy setting the owner of those domains may have published. In other words, if it's in the from address, it's always going to be the policy that applies, no matter what.

The real fix for the issue is to figure out how to get it so only your own domain name shows up in the from address. That might necessitate a change in your message flow process. It might make you have to reconsider whether or not you forward on messages through your system at all. Or you might have to rewrite headers, if you still want to be able to forward on that mail.

Need to contact

On a mailing list I subscribe to, someone recently asked for assistance with getting mail delivered to Microsoft's and domains. Apparently the poster works for an internet provider that had a compromised account or two, and Microsoft was blocking their mail as a result.

A kind soul posted this reminder in response:

"The most efficient and effective way to address any deliverability problem is by submitting the issue to our dedicated deliverability support team. Senders can do this by filling out a form with detailed information necessary to diagnose the problem. The form can be found here: Going directly to deliverability support will ensure that we have the right information to investigate the cause and recommend the right solutions quickly."

Those of us who have been around a while already have that URL bookmarked, but I thought I would share it here for new folks who might not already know it.

Check out this neat thing: Email Privacy Tester

Smart web developer and systems admin Mike Cardwell put together something neat that I think you'll want to check out: Email Privacy Tester. Plug in your email address, and his system will send you an email message. That message will contain a whole bunch of different types of active content in various different wrappers and encodings, to see which of them are triggered by your MUA (mail user agent; aka email client). I did a quick test to a Gmail account and I already see one thing that I don't like, something Gmail executes automatically without asking me.

DMARC does only one thing (but pretty well)

DMARC (specifically, DMARC with a p=reject policy) does one thing: It makes it very difficult for somebody to use your domain in a from address without your permission. It doesn't stop spam from open relays, open proxies, snowshoeing network blocks, nor does it prevent people from ignoring CAN-SPAM and continuing to mail you after you have unsubscribed.

It doesn't do all those other things; but the one thing it does, it seems to do it very well.

It has limitations; yes. It doesn't specifically do anything the cousin domain problem (deceptively-registered domains with similar, but not exactly the same names). It makes mailing list management more complex. And it makes it so for the most part, users of email service providers (ESPs) cannot use Yahoo or AOL addresses as from addresses (because Yahoo and AOL publish strict DMARC policies).

Is anybody saying that DMARC is a magic bullet? I don't think so, but a better question is -- Does DMARC help? Yes, says Yahoo.

But spammers eventually moved on to forging one of Yahoo's domains, so it was a pointless exercise, others have said. Pointless exercise? I don't agree with that at all. It's true that Yahoo only published a strict policy for one of their domains; it's almost like they decided to lock only one door first, either because it was the most abused, or perhaps because you have to start somewhere (and maybe want to see how that goes before adding others).

But if I were a Yahoo or AOL, or a financial institution, or well known retail brand, would I think it is a win; a gain, quite likely a long term one, if I could keep bad guys away from using my domain in the from address of their bad mail? Yes, I would. DMARC helps. And I think when you look at who is implementing DMARC, I suspect that I'm not the only one who feels that way.

This reminds me so much of the days when I first got involved in spam fighting. Open relaying mail servers were a big bad problem. Spammers exploited them regularly and with great vigor. I was so tired of dealing with spam from open relaying mail servers that I started to block it, an effort that ended up becoming the MAPS Relay Spam Stopper, a coordinated third party blacklist that easily allowed mail system administrators to block mail from open relaying mail servers.

Spammers cried about being blocked. But not just spammers; there were also a non-zero number of people who claimed that I was part of some big conspiracy to wreck email. People called my employer, trying to get me fired. A number of people threatened to sue. A few high-profile savvy internet users like John Gilmore, explained that they needed to be able to legitimately relay mail for other people, and that blocking mail from those servers was akin to censorship.

Somehow, we survived all of that. Eventually, people seemed to accept this change. We got to a point where, while you do still see open relays out there from to time, there's a general consensus that it's a bad way to configure a mail server. But for us to get there, a number of us had to first band together and take action; personally implementing policies wherein we block mail from misconfigured servers used to shovel abusive, unwanted mail, while people who didn't understand why it mattered gave us hell for at the time.

I find a lot of parallel there; my point, other than I'm old and 1998 was a long time ago, is that I have a feeling that this will be a non-issue in a few years, and even if sites don't broadly implement DMARC with a p=reject policy, enough of them will do so that you're truly going to have to just deal with it.

OpenDKIM & SpamAssassin Gotchas on Ubuntu 12.04

Allow me to share with you my rough notes compiled during my recent configuration of email and DKIM on a new Ubuntu VPS installation. Hopefully these helpful hints will help the next poor soul trying to get DKIM up and running on the first try:
  • SpamAssassin seems to want to fail DKIM keys from Gmail or Google Apps with an error of T_DKIM_INVALID. There's some noise online about this perhaps being an issue with clock synchronization, but it is more likely that you don't have one or more perl modules installed necessary for SpamAssassin to properly decode the DKIM key. The fix turned out to be simple; installing these packages solved that issue:
    sudo apt-get install libmail-dkim-perl
    sudo apt-get install libcrypt-openssl-random-perl
    sudo apt-get install libcrypt-openssl-rsa-perl
    (Thank you, Henrik Schack, for the tip!)
  • If you are new to OpenDKIM's Authentication Results header, you're going to be confused by this. You'll see a lot of DKIM as having passed, but with a reason of "1024-bit key; insecure key." This made me start poking around, looking at file permissions for my various keys (I set up signing for multiple domains). I assumed I had done something wrong, but I couldn't find any issue no matter where I looked. It turns out that it is not really an issue at all. What the error message actually means is that the domain that send you the message isn't using DNSSEC. Long term? Sure, yeah, everybody should look at DNSSEC, but one thing at a time.
  • Here's what nobody tells you if you're DKIM signing multiple domains on the same server, using OpenDKIM: It is possible to interpret the opendkim.conf configuration file in a way that would lead you to add multiple sections starting with "domain," setting a selector for each and linking to different keys. Truth be told, OpenDKIM will only honor the LAST one of these sections, signing mail for only one of your domains. It won't generate any sort of error message, either, so it can be frustrating to understand what is happening. Remember, if you want to set up signing for multiple domains, look at how to configure the SigningTable and KeyTable settings in OpenDKIM.
Even with the challenges I've run into here and there as I set up my new server, I'm amazed at how easy overall it was to get everything working. Last time I tried to enabled DKIM locally was a few years ago, and I got stuck in some arcane technical issue and gave up. Either the process got a lot easier and more stable, or I am smarter today than I was then. For my ego's sake, I'll pretend it's the latter.

(Originally posted to my personal blog, but I think it makes more sense here since it's talking about email, spam filtering and authentication.)

106 miles to Chicago

If you've ever set up catch-all domain names, that accept mail destined to any address, or set up your MTA in a way where all mail is accepted before checking to see if the recipient is valid, then you've probably seen emails containing this quote: "It’s 106 miles to Chicago, we got a full tank of gas, half a pack of cigarettes, it’s dark… and we’re wearing sunglasses."

The movie isn't new to me, but this is the first time I've run across the quote in this context. Apparently, for a while now, some spammer has been trying to find open relaying mail servers and seems to use this quote in almost every open relay attempt. I guess they just got around to trying it some place where I would notice the attempts.