Not good. Just the sort of urgent, high-risk issue that ISP abuse desks really want to hear about. I sent email about it to the ISPs involved, including a copy of the original email. One of them went to iWeb, a big (tens of thousands of servers) hosting company.

This was the response:

<abuse@noc.privatedns.com>: host mott.privatedns.com[174.142.252.34] said: 554 rejected due to spam content (in reply to end of DATA command)

That’s iWeb’s main abuse address for their address space, as registered with ARIN. They even have a comment in their network registration that says “Please use abuse@noc.privatedns.com for abuse issues”.

For email related abuse (spam, malware email, botnets, phishing, viruses, …) almost all valid, actionable abuse reports will include a copy of the email involved. And that’s exactly the sort of content that content-based spam filters do their best to block. That means that putting content-based spam filters on your abuse or security role addresses will prevent you seeing most reports about abusive traffic coming from your network.

There are some companies that have an intentional policy of rejecting most spam reports sent to them so that their abuse metrics look better, and they don’t have to pay for abuse desk staff to handle the high volumes of abuse reports their customers provoke. “Mistakenly” putting spam filters on their abuse alias is one way of doing that – others include using non-standard abuse aliases, demanding reports come in only via web forms, requiring abuse reports be sent in non-human-writable formats while discarding all others, and many more. If you don’t want to behave responsibly it’s easy enough to dodge those reports.

Legitimate companies really want to know about abusive traffic sooner rather than later, so they can shut it down and mitigate the damage as quickly as possible. Email systems are complex, though, and it’s quite easy for an upgrade to spam filtering at a companies main mailserver to mistakenly by applied to abuse@ and security@ aliases – especially when spam filtering or email services are outsourced. And if you’re a company that uses dozens of domains it’s easy to lose track of where mail to abuse@ some of those domains ends up.

If you’re responsible for email, abuse or security at your organization it’s worth occasionally checking that your role accounts actually work. Find yourself a fairly obvious bit of spam, then forward it to your abuse@ role address (with a sentence or two telling your abuse desk that you’re just testing, and can they reply to your mail so you know they received it).

Real spam sent directly to abuse@ role addresses can be a severe problem, but content-based filtering is not the way to deal with it. One approach that we suggest to our Abacus users is to prioritize reports that mention a URL or an IP address on your network, so that legitimate, actionable reports will “bubble up” above any spam.

So I went through my inbox and categorized the legitimate email I received, pulling out the consumer adverts from the personal mail, work-related commercial mail and so on, and charted it for the past couple of months, broken down into adverts for books, software, “tech” – consumer electronics / computer equipment / software etc., and everything else.

The vertical grid marks each Monday, including the obvious spike on Cyber Monday, November 28th. The regular cycle of junk mail early in the work week, followed by quiet over the weekend is pretty clear. And sure enough, there’s a significant increase on Cyber Monday and the few days beforehand, dominated by consumer goods, tech and otherwise.

Excluding high traffic discussion lists, the mail I was sent over the period of this chart was:

2.6% Consumer-targeted, opt-in commercial bulk email (as shown in the chart)

7.1% Other legitimate email (1:1, social media notifications, business-related mail, some discussion lists)

90.3% Spam

And, no, I didn’t buy anything on Cyber Monday.

My bayesian filter gets trained mostly by me hitting “this is spam” when spam makes it to my inbox. If I’m expecting an email “immediately” – something like a mailing list COI confirmation or email as part of buying something online – I’ll check my spam filter and move the mail to my inbox in the rare case it ended up there. Other than that I let it and spamassassin chug along with no tweaking.

I’m starting a data analysis project, based on my own inboxes, and as part of that I’m using some tools to look for false positives in my junk folders, and manually fixing anything that’s misclassified. I’ve been doing this for a couple of hours now, and I’ve found some interesting things.

1. Simple content filters work remarkably well out of the box, at least for my mail stream. Spectacularly well. There’s very little in the way of false positives. Very, very little.
2. Of those false positives there’s nothing I’d have been bothered about. It’s generic, unexciting junk mail.
3. Most of the systemic false positives seem to be correlated with the senders doing something bad. Heathrow Express, for instance, sent me mail every two weeks or so since I’d signed up. Then for no obvious reason they stopped sending for three months, then started sending again. Every mail they sent after that pause ended up in the junk folder, and I never missed them.
4. I get regular newsletters from ThinkGeek. Every one of those goes to the inbox. I occasionally get mails from them about my account (“you’ve got 420 geek points left”) that are kinda transactional, but not something I expect to see – and they all end up in the junk folder. Several other senders do the same thing, and get the same result.
5. Several companies have used tagged addresses to send me newsletters for a while, and also used them to send unsolicited facebook invites (to the tagged address, from facebook servers). The regular newsletters all go to the inbox, while the facebook invites all go to the junk folder. “Legitimate” facebook mail, meanwhile, keeps going to the inbox.
6. Apple send me a lot of newsletters – I’m a Mac and iPhone developer, I get their consumer newsletters, transactional stuff from our local store – lots and lots of newsletters. They all made it to the inbox except for one. The one that ended up in the junk folder was a one-off about recycling, and it wasn’t up to their usual design standards – it had ugly big green “call to action” headlines in it, very different to their usual clean design.
7. Just one sender hit the junk folder every time. The distinctive thing about their messages (apart from them not being something I missed) was that the plain text part of them was dreadful, just a bad lynx dump of the html section. Even a “No plain text for you! Go to this link!” would have been better.

I was surprised at how effective this simple content-based filtering setup had worked with little tuning other than hitting the this-is-spam button – both in it’s accuracy at removing spam while keeping a very low false positive rate, but also how well the false positives matched my judgement of “Meh. This mail isn’t interesting.”.

We spend a lot of time talking about the things you should do to make the mail relevant to the recipient – compelling content, consistent, predictable delivery schedules, clear consistent branding, use of a single consistent mail stream to communicate with a recipient rather than several different streams. Until I went through this exercise it wasn’t clear to me how much of an effect those things also have on fairly simple recipient-trained filters.

Another one should be “How does what you’re doing look to a typical recipient?”.

I’ve received several pieces of spam recently from senders who were ticking quite a lot of the “email best practices” checkboxes, but who completely blew it by not looking at it from the recipients point of view. The mistakes they’ve made, and the things to learn from them, and much the same, so I’ll just give one example.

“Likes Music” is not the same as “Likes Groupon Clones”

I’ve been a subscriber to our local radio station’s mailing list for years – promos KFOG is running, local gigs, that sort of thing, all in a newsletter sort of format. They recently sent out an ad for a Groupon clone called “SweetJack” – on it’s own, not as part of a newsletter. I’m not interested, and I think it’s a fairly poor pitch and won’t work well for their demographic, but fair enough. A couple of weeks later I start getting spam from SweetJack, thanking me for signing up – to the tagged email address I’d only given to KFOG. And no mention of KFOG at all.

Most recipients are just going to see this as spam out of the blue from SweetJack, and hammer on the “This is Spam” button until it goes away. That’s dreadful for SweetJack’s reputation, and is going to hurt their delivery.

Recipients paying more attention are going to notice that the first they heard of SweetJack was an out of the ordinary promo by KFOG, and then they start getting spam from SweetJack. They’re likely to assume that KFOG sold their email addresses to SweetJack – and that they’re sending their spam to an email address that only KFOG has in my case confirms that. That’s going to be dreadful for SweetJack’s reputation and going to damage the relationship between KFOG and their existing subscribers. A dreadful idea.

Digging down deeper, it seems that while KFOG being bought out by media behemoth Cumulus Media a few years back didn’t damage their on-air content, it did change the amount of respect they have for their subscribers. SweetJack is a new Groupon clone started by Cumulus Media. They did have legitimate access to the KFOG mailing lists, sorta. It’s probably not an AUP or privacy violation. It’s just the sort of thing an eager marketing guy at the corporate owners would think was a great idea, to leverage the value of their existing subscribers.

But it would have been a pretty bad idea had they carried it out perfectly, with clear messaging and transparency to the recipients. And they blew their one opportunity to do it well, and I’m betting that most of the recipients have SweetJack categorized as “spammers”, both mentally and in their mail clients.

1. Not a real email marketing rule.

What would you do differently if all those recipients were people you knew? Friends, colleagues, family – people with faces and names and stories and real relationships with you, rather than a database query or a spreadsheet full of addresses? Would you send the same emails if you expected to be meeting some of the recipients for a drink after work the next day, or handing out candy with them this evening?

And on the flip-side of that… if a company wanted you to send a typical junk message to everyone you know – coming from “you” directly to the inboxes of all your friends, associates, colleagues and family – would you do it? If you would, how much cold, hard cash would you want to be paid for each message sent?

I really want to know what you think. Leave me a comment.

The dkim working group has completed its primary charter items, and is officially closing. The mailing list will be retained for future discussions involving dkim. The list archive will also be retained.

The dkim working group was primarily focused on DomainKeys Identified Mail (DKIM) Signatures and DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP) (RFC 5617). We applaud the working group for progressing DomainKeys Identified Mail (DKIM) Signatures from proposed standard (RFC 4871) to Draft Standard (RFC 6376). The working group also produced the following Informational RFCs: Analysis of Threats Motivating DomainKeys Identified Mail (DKIM) (RFC 4868), DomainKeys Identified Mail (DKIM) Service Overview (RFC 5585), Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol (RFC 5016), and DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations (RFC 5863). The proposed standard DKIM And Mailing Lists (RFC 6737) was the final RFC produced by the working group.

What does this mean for DKIM-the-protocol?

DKIM as a protocol is finished and stable. It’s possible that there could be an incompatible “DKIM version 2″ in the future, but it’s fairly unlikely. It’s also possible that there’ll be a clarification of the existing spec in the future, if someone flushes out some bugs or inconsistencies while they’re implementing it, but that won’t break any existing usage.

If you want to attach an identifier to mail you send, or you want to use those identifiers to handle whitelisting or reputation-tracking or to drive domain-based feedback loops for mail you receive, DKIM is the way to do it.

What’s left to do?

DomainKeys Must Go

DomainKeys was the forerunner to DKIM. It’s been obsolete for several years and at this point nobody should be signing with it (or paying any attention to DomainKeys signatures). I’ve seen several cases recently where attempting to support both DomainKeys and DKIM lead to operational problems with the DKIM signing. It’s dead, let it go.

Good operational practices for signing with DKIM

This is the big bit of work left to do. While verifying a DKIM message and extracting the d= identifier from it is very well-defined, how best to sign with DKIM – including how best to do key management, key delegation and what DKIM options to use when signing – still hasn’t crystallized. Our suggestions for that are here: www.dkimcore.org

Configuration API support in smarthosts

While messages can be signed with DKIM anywhere in the mail pipeline they’re almost always signed at the sender smarthost. Many of the smarthosts added DKIM support by evolving the code they already had to sign with DomainKeys, which was a good engineering decision at the time. But DKIM is a much more flexible protocol than DomainKeys was, yet I’m told some of the smarthosts haven’t evolved far enough and only really support a “DomainKeys-like subset” of DKIM. Limited APIs like that reduce your flexibility in how you deploy DKIM, and will mean you can’t even try some of the smarter ways to use it.

As a minimum, your smarthost should be able to sign a message with any arbitrary private key / d= value pair rather than being tied to any email address or domain in the email headers. If it can’t do that, it’s not really supporting DKIM. If it can sign a message twice or three times efficiently – while processing the body of the message just once – that’s a DKIM feature that’s likely to be useful for ESPs.

Some sort of API to allow key management automation (deployment, delegation, rotation and invalidation) would make rich DKIM use much easier to deploy at scale, but I don’t know if anyone has looked at that sort of support in smarthosts yet. Anyone know?

Semantics

There’s still some misunderstanding about what some elements of DKIM mean.

What is the identity that DKIM conveys? (Usually the “d=” field, though the additional information in the “i=” field might sometimes be part of that too).

What does the selector mean? (Absolutely nothing! If you try and claim it does, you’re doing it wrong. It’s intended for key rotation and key delegation, and attempting to use it for anything else will make key management harder, and likely end up making the signature less secure).

What do multiple signatures mean? (That it was signed by each of those domains. None is more important than the others, and there’s no “primary” signing domain. What you do with that information is a whole other thing, though).

What about ADSP?

ADSP is effectively dead. The discussions that happened as part of it’s development, and the results (both good and bad) of limited testing with it will probably lead to something with similar goals in the near future – more limited in scope, probably, but less fundamentally flawed.

Whence SPF?

SPF isn’t dead, by any means. I expect some mail recipients will check both DKIM and SPF for the near future (though I’ve heard some interesting discussion about receivers keeping a local cache of DKIM results correlated with sending IP which may end up replacing one common SPF-based performance hack).

And what’s next?

Thanks to everyone involved in the DKIM specification process for creating this unobtrusive, robust way of attaching an identity to an email!

It’s going to be interesting to see what features people build on top of the DKIM foundation.

I sent a spam report to abuse@mailchimp last week. The spam was nothing special – it was an advert about bouncy castles from a small company local to me sent to a tagged address used to register a domain that expired several years ago, so I knew someone had purchased a “targeted” list. The mail I sent to mailchimp was just one line, mentioning where the email address had come from and a full copy of the email with headers – again, nothing special.

The response I got back from Meredith was particularly good, so I thought I’d share it.

Hi Steve!

Thank you for getting in touch with us with the info on the sender. I found the account and turns out they were already suspended for excessive bounces. The account is permanently banned going forward and we’ll do everything we can to ensure this doesn’t happen again! Meredith @ MailChimp Abuse

I received that less than 90 minutes after sending in the report. In less than fifty words it tells me an awful lot about MailChimp and their abuse policies and procedures.

• MailChimp have an abuse desk
• They actually look at each report, rather than handling them entirely automatically
• They have the time to send what looks like a hand-written reply
• They’re staffed at an appropriate level for the level of spam reports they receive and/or have good automation
• … all of which means that they must run a pretty clean ship – ESPs who don’t can drown in many thousands of reports a day
• They understand that the information about where an email address was acquired from is important, which means they’re really a competent abuse desk, not just tier one customer support
• They have automation in place to detect and shut down bad customers even before getting complaints
• They’re taking appropriate action against the customer to stop the spam (sometimes getting rid of the customer is appropriate, sometimes educating them is)
• They’re humble enough to know that even if they’re handling things well, there’s always room for improvement

We’ve worked with MailChimp in the past, so it’s quite possible Meredith recognized my name, despite it being sent from my personal account to their abuse role account. Even so, it tells a strong story – and if an abuse desk is aware enough of people in the industry and paying enough attention to notice them in the incoming abuse@ mail stream without cues, that’s something in itself.

How an ESP responds to a complaint tells a much stronger story about their attitude to bad behaviour by their customers than a dozen webpages of policy and claims of zero tolerance. If that sort of response were sent to ISP postmaster or NOC staff, a blacklist staffer or some other filter operator it would have a direct effect, but consistently good responses to reports of spam also builds a reputation within the legitimate email industry – and that reputation can affect how others will work with you when you need them to.

One of the tenets of software QA is “Assume users are malicious”. That’s also one of the tenets of security engineering, but in a completely different way.

A security engineer treats users as malicious, as the users he or she is most concerned about are crackers trying to compromise their system, so they really are malicious. A QA engineer knows that if you have enough users in the field, making enough different mistakes or trying to do enough unusual things, they’ll find all the buggy little corners of your application eventually – and crash it or corrupt data more reliably than a genuinely malicious user.

As a QA engineer it’s easier to personify the forces of chaos you’re defending against as a single evil weasel than a million random monkeys.

In the bulk email world the main points where you interact with your users are signup, confirmation, unsubscription and click-throughs. Always think about what the evil weasel will do at that point.

Signup

• The weasel will enter an invalid email address – check it at signup time
• The weasel will enter a valid email address that belongs to someone else – there are many ways to defend against that, none of them clearly the best
• The weasel will enter leading or trailing spaces – strip ‘em off
• The weasel will enter non-ASCII characters in their name – and that’s OK unless it breaks your data handling
• The weasel will enter non-ASCII characters in their email address – and that’s probably not OK, not yet, anyway
• If you treat a character as “magic” anywhere in your data flow (whether that be a quote, a comma, tab or even a newline) your weasel will sneak it in to their data somewhere – always sanitize your inputs as soon as possible
• If you rely on client-side validation to ensure clean data, your weasel will turn off javascript – always validate server-side, even if you’re validating client-side
• The weasel will sign up multiple times, in different places – yet they don’t really want multiple emails
• The weasel has a million email addresses, and will sign them all up if you send him a million tchotchkes to do that – don’t incentivize that sort of behaviour
• The weasel has, inexplicably, a thousand friends and will sign them all up if you send him a thousand tchotchkes to do so – which could conceivably be what you want, but be very, very sure before incentivizing for it
• The weasel surely has the email addresses of 100,000 strangers who he’ll tell you are his friends – be very careful about offering incentives for signups, as the weasel will happily have you send 99,999 pieces of unwanted spam so that he gets his nickel for the one recipient who buys from you

Confirmation

• The weasel will run antivirus software that automatically prefetches everything in the email – either have your “yes I want to subscribe” link go to a page that requires additional action, or have a “hidden” link in the email that invalidates the opt-in link if it’s followed
• The weasel will visit the confirmation link multiple times, and will complain if it welcomes them to the list each time – consider “You’re already subscribed to…” type language, if they’re already subscribed
• The weasel will edit the URL the opt-in link goes to, changing the email address embedded in it – so make sure that it’s an opaque token or cryptographically signed
• If the opt-in link contains the number 10237, the weasel will also go to the same URL with the number 10236 or 10238 – make sure that they can’t affect other peoples signups that way
• The weasel will sign up for your list, then unsubscribe, then six months later find the old confirmation email and click on the opt-in link – make sure that doesn’t work, instead routing them to a signup page, perhaps

Unsubscription

• Your weasel doesn’t know their email address – make sure they don’t need to know it to unsubscribe
• Your weasel does know other peoples email addresses – make sure they need to know more than that to unsubscribe other people
• The weasel will run antivirus software that prefetches URLs in the email – so either require them to hit a button on the destination webpage or have a “hidden” link in the email that invalidates the opt-out link if it’s followed
• The weasel will hit the “this is spam” link to unsubscribe – make sure that doing that does suppress mail to them
• The weasel will appear almost intentionally stupid in their inability to navigate the complexities of your unsubscription mechanism – make sure that they can contact a human, and that that human has the power to suppress mail to them
• The weasel will share the email you send them with other people, who’ll then click on the unsubscription link – give them the email address on the unsubscription page, so they’re less likely to inadvertently unsubscribe the original weasel

Click-throughs

• The weasel won’t remember their username or password – so don’t make them log in to see the content you link to from the email
• The weasel will forward your email on to other people – so make sure the other people can’t see any of the weasel’s PII or spend the weasel’s money without more authentication
• The weasel will click on the links in the email repeatedly – so make sure that’s OK
• The weasel will suddenly find email you sent them three years ago, and expect the links to still work
• The weasel will try to copy and paste URLs from the text part of your email – so try and keep them under 70 characters or so

There are countless other things the evil weasel and the random monkeys will do to throw a spanner into your systems. Bear them in mind when you’re putting infrastructure, or a campaign, or policies together.

One common thread is that the ESP customers being listed aren’t the sort of sender who you’d expect to be a significant source of abuse. Real companies, gathering addresses from signup forms on their website. Not spammers who buy lists, or who harvest addresses, or who are generating high levels of complaints – rather legitimate senders who are, at worst, being a bit sloppy with their data management. When Trend blacklist an IP address due to a spamtrap hit from one of these customers the actions they are demanding before delisting seem out of proportion to the actual level of abuse seen – often requiring that the ESP terminate the customer or have the customer reconfirm the entire list.

“Reconfirming” means sending an opt-in challenge to every existing subscriber, and dropping any subscriber who doesn’t click on the confirmation link. It’s a very blunt tool. It will annoy the existing recipients and will usually lead to a lot of otherwise happy, engaged subscribers being removed from the mailing list. While reconfirmation can be a useful tool in cleaning up senders who have serious data integrity problems, it’s an overreaction in the case of a sender who doesn’t have any serious problems. “Proportionate punishment” issues aside, it often won’t do anything to improve the state of the email ecosystem. Rather than staying with their current ESP and doing some data hygiene work to fix their real problems, if any, they’re more likely to just move elsewhere. The ESP loses a customer, the sender keeps sending the same email.

If this were all that was going on, it would just mean that the MAPS blacklists are likely to block mail from senders who are sending mostly wanted email.

It’s worse than that, though.

The other thread is that we’re being told that Trend/MAPS are blocking IP addresses that only send confirmed, closed-loop opt-in email, due to spamtrap hits – and they’re not doing so accidentally, as they’re not removing those listings when told that those addresses only emit COI email. That’s something it’s hard to believe a serious blacklist would do, so we decided to dig down and look at what’s going on.

Trend/MAPS have registered upwards of 5,000 domains for use as spamtraps. Some of them are the sort of “fake” domain that people enter into a web form when they want a fake email address (“fakeaddressforyourlist.com”, “nonofyourbussiness.com”, “noneatall.com”). Some of them are the sort of domains that people will accidentally typo when entering an email address (“netvigattor.com”, “lettterbox.com”, “ahoo.es”). Some of them look like they were created automatically by flaky software or were taken from people obfuscating their email addresses to avoid spam (“notmenetvigator.com”, “nofuckinspamhotmail.com”, “nospamsprintnet.com”). And some are real domains that were used for real websites and email in the past, then acquired by Trend/MAPS (“networkembroidery.com”, “omeganetworking.com”, “sheratonforms.com”). And some are just inscrutable (“5b727e6575b89c827e8c9756076e9163.com” – it’s probably an MD5 hash of something, and is exactly the sort of domain you’d use when you wanted to be able to prove ownership after the fact, by knowing what it’s an MD5 hash of).

Some of these are good traps for detecting mail sent to old lists, but many of them (typos, fake addresses) are good traps for detecting mail sent to email addresses entered into web forms – in other words, for the sort of mail typically sent by opt-in mailers.

How are they listing sources of pure COI email, though? That’s simple – Trend/MAPS are taking email sent to the trap domains they own, then they’re clicking on the confirmation links in the email.

Yes. Really.

So if someone typos their email address in your signup form (“steve@netvigattor.com” instead of “steve@netvigator.com”) you’ll send a confirmation email to that address. Trend/MAPS will get that misdirected email, and may click on the confirmation link, and then you’ll “know” that it’s a legitimate, confirmed signup – because Trend/MAPS did confirm they wanted the email. Then at some later date, you’ll end up being blacklisted for sending that 100% COI email to a “MAPS spamtrap”. Then Trend/MAPS require you to reconfirm your entire list to get removed from their blacklist – despite the fact that it’s already COI email, and risking that Trend/MAPS may click on the confirmation links in that reconfirmation run, and blacklist you again based on the same “spamtrap hit” in the future.

We have been in a pretty lengthy back and forth with maps. Its just a disaster all around. We cleaned up around 200+ accounts, but they are still seeing trap hits. I finally got fed up and we just asked them outright “we cleaned up 200+ customers lists, and are still hitting traps? any chance you guys are clicking links?”. At this point they have a substantial amount of our IP space listed and are just making this painful. They haven’t had time to respond to our question, but at this point maps seems to be the new SORBS.An ESP’s take on the issue

We (Word to the Wise) aren’t an ESP – if we were then the risk of damage to our business due to publicly criticizing a blacklist would mean we wouldn’t be able to do it – so we don’t have first-hand experience of this behaviour. We have been told by six ESPs and an infrastructure company that Trend/MAPS has ongoing issues with inaccurate listings. Four of them have said that Trend/MAPS is clicking on links in email they’re sending, in some cases confirmation links. We’ve been provided data, including web access logs showing clicks on confirmation links in email sent to “trap” domains registered by Trend from anonymous Taiwanese consumer IP addresses. Many of the “trap” domains are registered by a Director of “Core Tech” at Trend Micro, at a Taiwanese address.

These email addresses were confirmed over the past several years, and have been used to justify aggressive blacklisting of ESPs since. MAPS representatives also confirmed to two ESP representatives that they did sometimes click on links in email sent to their trap addresses during investigations – and that matches data provided to us by another ESP that suggests Trend/MAPS will sometimes go through and click on many of the links in a batch of emails, possibly including any confirmation or reconfirmation links in those emails.

So, it seems that the Trend/MAPS blacklists are being run in a way that will sometimes blacklist sources of 100% COI wanted email, as well as sources of likely wanted email that’s not entirely COI. Conversely, it’s pretty easy to identify or block the trap domains they’re using (a simple google search will find thousands of them, and null-routing the five or so MXes they use would block all email to them) so any moderately smart spammer could easily avoid being listed by them. That suggests the data quality is probably poor.

It’s even worse than that, though.

Trend/MAPS don’t only run their own spamtrap domains. They also are fed data by spamtraps run by consumer ISPs, including Comcast. There’s data from the ESPs we’ve been talking to that show that senders that have been blacklisted by Trend/MAPS for “spamtrap hits” are sending email to @comcast.net addresses that had previously been confirmed by the same anonymous Taiwanese consumer IP address as was found clicking on confirmation links. So it’s likely that Trend/MAPS habit of clicking confirmation links in mail sent to “spamtraps” is poisoning ISPs independent spamtrap data, as well as their own published blacklists.

ESP representatives have been asking Trend Micro about these issues for months. On Wednesday we invited a MAPS rep to comment on the issue as we were planning on writing about it, but didn’t hear anything back beyond a request for specific examples. We declined to provide that for several reasons – it’s not our data to share, doing so would reveal which ESPs provided it to us, and it’s all been provided to Trend/MAPS by the ESPs concerned so they already have the data and are aware of the issues.

Trend/MAPS are tainting the spamtraps they use, by setting them up such that they’re likely to catch sources of mostly wanted email, including sources of 100% COI email. If they were doing that as part of a survey or research project, that would be OK, though the data would likely not be of much value. Instead, though, they’re accusing the senders of this mail of spamming, listing them on their blacklist and making unreasonable demands of the senders before they’ll remove their listing. As MAPS are also selling this data to large US consumer ISPs who use it to block email, the senders don’t have much choice but to comply with those unreasonable demands. (Update 8/9/11: A sender who was listed by MAPS in the last few days is seeing inbox delivery at the major US ISPs we believed were Trend/MAPS customers. It appears that our data on MAPS usage is out of date.) I also wonder how accurate Trend/MAPS are in how they represent their spam filtering services and blacklist data to those ISPs who use them – I doubt those ISPs are intending to buy a blacklist service that blocks wanted, COI email.

So here’s some short prescriptive advice in no particular order for “how to do email authentication at an ESP well” without the long discussions of alternative approaches and justification of each piece of advice.

1. Remove every trace of DomainKeys from your email flow
2. Sign all your email with DKIM
3. Publish SPF records
4. Have your SPF records finish with ~all, not -all
5. Ignore SenderID, unless you have delivery problems at Hotmail (and even then measure results rather than just assuming it will help)
6. Don’t publish ADSP records
7. Have the customer pick a single domain to tie their reputation to – ideally their “main” domain, but if that’s not possible then a customer-specific domain owned by the ESP is the next best thing (i.e. “customer.com” is ideal, but “customer.esp.com” is much better than just “esp.com”)
   1. Use that domain as the d= field when signing email (“d=customer.com”)
   2. Use that domain, or a sub-domain of it, in the From: field of the email (“From: Someone <someone@customer.com>” or “From: Someone <someone@fooble.customer.com>”)
8. Pick a good email address to use in the From: field, don’t change it lightly
9. Use two-part selectors for DKIM, one specific to you, the ESP, on the right and one for key rotation on the left (why do this?)
10. Use just what’s needed for DKIM – don’t use i=, l=, q=, x= or z= in the signature, don’t use g= or s= in the published key
    1. dkimcore.org has more specific advice about which subset of DKIM to sign with
11. Make sure your SPF records are valid
12. TLS/SSL isn’t useful for authenticating mail (it’s great for connecting to a smarthost from a mail client, but not for connections from the smarthost)
13. None of SPF, DKIM or TLS are really designed to protect or hide the contents of a message
    1. Customers who really want that could look at S/MIME or PGP
    2. … but better to design their business model such that they don’t need to, as client support is spotty at best
14. Empirical evidence that doing something will make a customer happy trumps any of the above
    1. maybe because there’s evidence SenderID or ADSP or somesuch really helps that customer
    2. or maybe because the customer just wants it, even if there’s no evidence it would help

Mail client use of authentication data is still in flux, so it’s likely that some of this may change slightly (interaction between SPF and DKIM d= domains, for example) but it’s a pretty good base to start with today.