Recent Posts

Tracking consumers

In an effort to more closely observe the group’s buying habits and personal behaviors, a growing number of corporations are turning to tag and release programs to study American consumers, sources confirmed Friday. The Onion
Read More

Authenticating with SPF: -all or ~all

What is SPF?

Sender policy framework (SPF, RFC 7208) is an authentication process that ties the 5321.from (also known as the mail from, envelope from or return path) to authorized sending IP addresses. This authorization is published in a TXT record in DNS. Receivers can check SPF at the beginning of a SMTP transaction, compare the 5321.from domain to the connecting IP address and determine if that IP is authorized to transmit mail.

What are affiliate mailers?

Affiliate mailers collect email addresses and then rent access to those addresses out to 3rd parties. There are a wide range of vendors that fall into the affiliate category. Some vendors compile lists through co-registration, others compile lists themselves through website opt-ins and some affiliate vendors fulfill mailing requests by hiring affiliates. There are, of course, some senders in the affiliate space that don’t even pretend to send opt-in mail, they just buy, compile or harvest addresses and blast mail to those addresses.

Updates to commercial MTAs

Last week Message Systems announced the release of Momentum 4. This high volume MTA has a large number of features that make it possible for large volume senders to manage their email and their delivery. I had the opportunity to get a preview of the new features and was quite impressed with the expanded features. Improvements that caught my eye include:

Stop telling me how great Spamarrest is

Late last year, Al wrote a piece discussing how Spamarrest lost a court case. In the comments on that piece I described how much I really detest Spamarrest because of all the spam I get from Spamarrest users. Every few weeks, someone notices that post again and points it out to Spamarrest users who then come over here to tell me how wonderful Spamarrest is for them.
I Get It. You like Spamarrest because it keeps spam out of your inbox.
The problem is Spamarrest (and any other challenge response setup) contributes to spam in my inbox. I have addresses that get forged into spam all the time. When that happens, I get dozens of Spamarrest challenges, clogging up MY inbox.
I don’t want to do your spam filtering for you. I really don’t. And if you ask me if you should receive a piece of email, I am going to tell you yes. I did that for a while; when I got a challenge from someone I’d answer it in the affirmative. Eventually I got tired of it and sent all mail from @spamarrest.com to /dev/null.
Am I missing out on corresponding with some brilliant and wonderful people? Maybe. But from my perspective, 100% of the confirmation requests I receive from Spamarrest are spam. I’m just thankful that Spamarrest makes it easy to identify and throw away their requests so I don’t have to handle someone else’s spam load in addition to my own.
This is a long way to say I’m closing comments on the older Spamarrest post, so don’t bother telling me what a great spam filter it is. The same thing that makes it a great spam filter for you makes it a total source of spam for me.

A good example of a privacy change notification

A friendly reader sent me this example of the notice Coldwater Creek sent out to subscribers this week.
Coldwater Creek was a major retailer that recently filed for bankruptcy. As part of that, they’re transferring assets, including customer lists, to a holding company for potential use when the company is re-launched. That holding company is also the parent company of Talbots, another clothing retailer.
The thing I really like about this notice is that it’s clear what the company is doing with customer information. Not only that, the customer gets to control their information and with whom it gets shared.

Spam filters and mailbox usage

It’s no secret that I run very little in the way of spam filters, and what filters I do run don’t throw away mail, they just shove it into various mailboxes.
Looking at my mailboxes currently I have 11216 unread messages in my mail.app junk folder, 10600 unread messages in my work spam assassin folder and 29401 messages in my personal spam assassin folder (mail getting more than +7 on our version of spam assassin gets filtered into these folders). I went through and marked all of my messages read back in mid-January. That’s a little over 50,000 messages in a little over 5 months or slightly more than 2700 spams a week.
But these are messages I don’t have to deal with so while they’re somewhat annoying and a bit of “wow, my addresses are everywhere” they’re not a huge deal. I have strong enough filters for wanted mail that I can special case it.

Are FBLs required for a clean mail stream?

A few years ago I would have said that a good mailer could have a good mailing program without necessarily participating in FBL programs. I’m not convinced that’s true any longer. As the mailbox providers and ISPs develop more complex filtering methodologies, it’s important for senders to get any possible feedback from recipients. That press on the this-is-spam button may not actually mean the mail is spam, but it does mean that recipient really didn’t like the message.
Getting the feedback lets a sender fine tune their sending processes and better target what their recipients want to receive.
I do think that senders need to know what users are saying about their email. When users hit the T-i-S button then that is valuable information about how the recipients think about the mail. Senders really on top of things can use positive data (opens and clicks) and negative data (FBLs and unsubscribes) to monitor how wanted their email is and make adjustments to their sending stream.

Spammers react to Y! DMARC policy

It’s probably only a surprise to people who think DMARC is the silver bullet to fixing email problems, but the spammers who were so abusing yahoo.com have moved on… to ymail.com.
In the rush to deploy their DMARC policy, apparently Yahoo forgot they have hundreds of other domains. Domains that are currently not publishing a DMARC policy. Spammers are now using those domains as the 5322.from address in their emails. The mail isn’t coming through any yahoo.com domain, but came through an IP belonging to Sprint PCS.

This is just one example of how spammers have reacted to the brave new world of p=reject policies by mailbox providers. If only the rest of us could react as quickly and as transparently to the problems imposed by these policy declarations. But changing software to cope with the changes in a way that keeps email useful for end users is a challenge. What is the right way to change mailing lists to compensate for these policy declarations? How can we keep bulk email useful for small groups that aren’t necessarily associated with a “brand”?
The conversation surrounding how we minimize the damage to the ecosystem that p=reject policy imposed hasn’t really happened. I think it is a shame and a failure that people can’t even discuss the implications of this policy. Even now that people have done the firefighting to deal with the immediate problems there still doesn’t seem to be the desire to discuss the longer effect of these changes. Just saying “these are challenges” in certain spaces gets the response “just deal with it.” Well, yes, we are trying to deal with it.
I contend that in order to “just deal with it”, we have to define “IT.” We can’t solve a problem if we can’t define the problem we’re trying to solve. Sadly, it seems legitimate mailers are stuck coping with the fallout, while spammers have moved on and are totally unaffected.
How is this really a win?

May 2014: The month in email

It’s been a busy and exciting month for us here.
Laura finished a multi-year project with M3AAWG, the Messaging, Malware and Mobile Anti-Abuse Working Group (look for the results to be published later this year) and continued working with clients on interesting delivery challenges and program opportunities. Steve focused on development on the next version release of Abacus, our flagship abuse desk tool, which will also be available later this year.
And as always, we had things to say about email.
The World of Spam and Email Best Practices
We started the month with a bit of a meta-discussion on senders’ fears of being labeled spammers, and reiterated what we always say: sending mail that some people don’t want doesn’t make you evil, but it is an opportunity to revisit your email programs and see if there are opportunities to better align your goals with the needs of people on your email lists. We outlined how we’ve seen people come around to this position after hitting spamtraps. That said, sometimes it is just evil. And it’s still much the same evil it’s been for over a decade.
We also wrote a post about reputation, which is something we get asked about quite frequently. We have more resources on the topic over at the WiseWords section of our site.
Gmail, Gmail, Gmail
Our friends over at Litmus estimate Gmail market share at 12%, which seems pretty consistent with the percentage of blog posts we devote to the topic, yes? We had a discussion of Campaign Monitor’s great Gmail interview, and offered some thoughts on why we continue to encourage clients to focus on engagement and relevance in developing their email programs. We also wrote a post about how Gmail uses filters, which is important for senders to understand as they create campaigns.
SMTP and TLS
Steve wrote extensively this month about the technical aspects of delivery and message security. This “cheat sheet” on SMTP rejections is extremely useful for troubleshooting – bookmark it for the next time you’re scratching your head trying to figure out what went wrong.
He also wrote a detailed explanation of how TLS encryption works with SMTP to protect email in transit, and followed that with additional information on message security throughout the life of the message. This is a great set of posts to explore if you’re thinking about security and want to understand potential vulnerabilities.
DKIM
Steve also wrote a series of posts about working with DKIM (DomainKeys Identified Mail), the specification for signing messages to identify and claim responsibility for messages. He started with a detailed explanation of DKIM Replay Attacks, which happens when valid email is forwarded or otherwise compromised by spammers, phishers or attackers. Though the DKIM signature persists (by design) through a forward, the DKIM specification restricts an attacker’s ability to modify the message itself. Steve’s post describes how senders can optimize their systems to further restrict these attacks. Another way that attackers attempt to get around DKIM restrictions is by injecting additional headers into the message, which can hijack a legitimately signed message. If you’re concerned about these sort of attacks (and we believe you should be), it’s worth learning more about DKIM Key Rotation to help manage this. (Also of note: we have some free DKIM management tools available in the WiseTools section of our site.)
As always, we’re eager to hear from you if there are topics you’d like us to cover in June.