Matthew Green reminded me of an old bit of spam lore.
It’s a canned response to someone’s New and Awesome and entirely unoriginal Final Ultimate Solution to the Spam Problem. It originated on the news.admin.net-abuse.email newsgroup, I think, maybe twenty years ago? While one or two details have changed it’s still applicable to most of the current generation of under-researched proposals.
Your post advocates a
( ) technical ( ) legislative ( ) market-based ( ) vigilante
approach to fighting spam. Your idea will not work. Here is why it won’t work. (One or more of the following may apply to your particular idea, and it may have other flaws which used to vary from state to state before a bad federal law was passed.)
( ) Spammers can easily use it to harvest email addresses
( ) Mailing lists and other legitimate email uses would be affected
( ) No one will be able to find the guy or collect the money
( ) It is defenseless against brute force attacks
( ) It will stop spam for two weeks and then we’ll be stuck with it
( ) Users of email will not put up with it
( ) Microsoft will not put up with it
( ) The police will not put up with it
( ) Requires too much cooperation from spammers
( ) Requires immediate total cooperation from everybody at once
( ) Many email users cannot afford to lose business or alienate potential employers
( ) Spammers don’t care about invalid addresses in their lists
( ) Anyone could anonymously destroy anyone else’s career or business
Specifically, your plan fails to account for
( ) Laws expressly prohibiting it
( ) Lack of centrally controlling authority for email
( ) Open relays in foreign countries
( ) Ease of searching tiny alphanumeric address space of all email addresses
( ) Asshats
( ) Jurisdictional problems
( ) Unpopularity of weird new taxes
( ) Public reluctance to accept weird new forms of money
( ) Huge existing software investment in SMTP
( ) Susceptibility of protocols other than SMTP to attack
( ) Willingness of users to install OS patches received by email
( ) Armies of worm riddled broadband-connected Windows boxes
( ) Eternal arms race involved in all filtering approaches
( ) Extreme profitability of spam
( ) Joe jobs and/or identity theft
( ) Technically illiterate politicians
( ) Extreme stupidity on the part of people who do business with spammers
( ) Dishonesty on the part of spammers themselves
( ) Bandwidth costs that are unaffected by client filtering
( ) Outlook
and the following philosophical objections may also apply:
( ) Ideas similar to yours are easy to come up with, yet none have ever been shown practical
( ) Any scheme based on opt-out is unacceptable
( ) SMTP headers should not be the subject of legislation
( ) Blacklists suck
( ) Whitelists suck
( ) We should be able to talk about Viagra without being censored
( ) Countermeasures should not involve wire fraud or credit card fraud
( ) Countermeasures should not involve sabotage of public networks
( ) Countermeasures must work if phased in gradually
( ) Sending email should be free
( ) Why should we have to trust you and your servers?
( ) Incompatiblity with open source or open source licenses
( ) Feel-good measures do nothing to solve the problem
( ) Temporary/one-time email addresses are cumbersome
( ) I don’t want the government reading my email
( ) Killing them that way is not slow and painful enough
Furthermore, this is what I think about you:
( ) Sorry dude, but I don’t think it would work.
( ) This is a stupid idea, and you’re a stupid person for suggesting it.
( ) Nice try, assh0le! I’m going to find out where you live and burn your house down!
It still very much applies. It just needs some mention of ( ) blockchain …
On Friday I mentioned spam coming from a BarkBox affiliate programme.
The original email is here. It’s not terribly exciting, it’s rather typical spam of the sort sent by professional spammers.
It’s validly DKIM and SPF authenticated, and DMARC-aligned. It includes invisible white-on-white padding text so that it doesn’t look like image-only spam to naive filters (using text from the BarkBox wikipedia page). It’s sent from a throwaway CentOS host on a second tier VPS provider. That is a single (templated) machine that handles sending the spam and serves the images and does the clickthrough handling – meaning that there is no reference in the spam to anything other than the throwaway host. And so there’s not really any way to track who the spammer is without subpoena power other than by following the money.
Let’s follow the money.
I’m assuming that the spammer and his associates aren’t using any particularly clever defensive measures against tracking (and if they are, meh, all I’ll have lost is some blog content). So I’m using a simpler approach than I’d use in an actual case, one that’s easier to demonstrate. I’m fetching each link manually with the curl command, and looking at the result manually.
“curl -D- http://example.com” is a really useful curl idiom. By default curl will fetch the page you give it and print out the content. If you add the flag “-D-” it will print the headers of the response as well as the body. That’s particularly important for looking at clickthrough links as in a normal “302 redirect” the destination URL is provided in the Location: header.
The full trace of me checking the chain of redirection links is here.
Hitting the long http://mindpowrr.bid/… link in the email it 302 redirects to https://seenior.bid/aa/bbp3/. seenior.bid feels like it’s probably owned by the same spammer as mindpowrr.bid, just from the misspelling and choice of TLD. It’s hosted on cloudflare, so the hosting is bulletproof and the TLS certificate is useless. The “bbp3” at the end of the URL is suggestive of it being a manually assigned tag for BarkBox promotions.
Fetching the seenior.bid URL shows a different way to redirect, a rather creative one. It uses a bootstrap modal component to display a “fake” dialog box with an html form containing a google recaptcha. Clever. People are used to having to click on those to continue, but any automated analysis isn’t going to click on the form submit button.
Clever. (Note those unsubscription links – I’ll come back to them later).
The spammer didn’t bother checking the response from the recaptcha when you submit the form, that’s not what it’s there for. In fact, they don’t even see the form results as the form posts to https://tinyurl.com/yalfp3x9 – and tinyurl is a commercial link redirector, not something that handles forms.
I know tinyurl don’t care whether I send it a GET or a POST, so I just use the same curl command , and tinyurl 302 redirect me to http://trkpaper.com/?a=21966&c=62394&s1=5702BBP3.
trkpaper.com is abovealloffers – an affiliate network. Marketers pay abovealloffers for clicks, abovealloffers pay anyone who provides them with clicks. Because the core of their business is distributing money for clicks it’s critical that abovealloffers keep track of who is sending them traffic. Looking at the URL it’s nicely transparent. “a=21966” is probably the identity of the affiliate (spammer). “s1=5702BBP3” has the same “bbp3” identifier in it, and is probably how abovealloffers are describing the particular campaign BarkBox is paying for. “c=62394”? Not sure, I’d guess it’s a client identifier.
Clicking on the trkpaper.com URL 302 redirects to a URL at https://aboveallurl.com/…, including all the parameters that were passed above.
Following the https://aboveallurl.com/… link does a simple 302 redirect to http://superchewer.barkbox.com/aao/?AFID=21966 – and that’s the advertiser. The AFID shows me that it’s an affiliate programme run by BarkBox rather than anything custom to abovealloffers.
Those unsubscription links are both using bit.ly as a link shortener. I love when people do that, as you can add a “+” on the end of any bit.ly URL to get the tracking metrics. The first one isn’t terribly interesting – it goes to a bland, EC2 hosted generic unsubscription form at “optout-pljz.net”, and has been clicked on three times.
The second one is their global unsub request. It’s been used a bunch of times, and it redirects to a page hosted on apexpoint.co.in. The path of the page is /unsub.php, and it only shows an unsubscription form if passed the right parameters. That tells me that this server is under the control of the spammer, and may belong to the spammer. That support@apexpoint.co.in is used as an alternate unsubscription route means it’s the latter. (And, to sum up just how the spammer approaches things, the unsubscription form doesn’t actually do anything at all if you try and use it).
So … apexpoint.co.in … The whoispocalypse has apparently affected Indian domains, so no help from whois. The website has been locked down, so the root page just throws a (broken) error. It’s hosted on a lower end US provider who’d be responsive to a subpoena but won’t be a source of information without one.
But it’s running a TLS webserver with a self-signed certificate:
Naman Kathal – naman627 – out of Bhopal, Madhya Pradesh province, India.
Searching for naman627 finds Naman’s twitter account and several member profiles on affiliate / spammer bulletin boards:
Dedicated servers 97% to 99% network uptime guarantee…
Hi,
If anyone need server’s for email marketing or any other stuff. Kindly contact me, I can provide server with Best Quality and Best Price with 24/7 quality support. You can also contact me on skype ID :- naman.kathal1 for more details.
Thanks
The company mentioned in Naman’s bio is the same one the only Naman Kathal on LinkedIn claims to own. And it’s in Bhopal. And it lists apexpoint.co.in as a project. And it’s website is on the same IP address as apexpoint.co.in. They’re one and the same.
Namal claims to be a CPA affiliate network (what abovealloffers actually is) but I suspect that’s aspirational and the spammer is either Namal himself, or maybe someone he sells his “server’s for email marketing” to.
So what most likely happened is that AboveAllOffers signs up for the BarkBox affiliate programme. BarkBox pay AboveAllOffers for clicks. AboveAllOffers pay anyone who’ll drive traffic to them, including spammers. Neither of them ask too many questions about where the traffic comes from.
BarkBox don’t really advertise their affiliate programme, rather they’ve mentioned it on social media and asked people to contact them via email to sign up for it, but I’ve seen affiliate networks talking about BarkBox promotions offering rates of $16 or 27% of the purchase. Definitely enough to be worthwhile if you’re sending enough email or you’re based out of India. Or both.
And that’s why Indian spammers are pumping out spam advertising BarkBox.
If I see BarkBox I think Spam.
That’s because, despite their marketing team effort, facebook and banner ad budget, the main place I see them advertised is via spam in my mailbox.
It’s not even good spam.
There’s quite a lot of it. Most of it looks much the same, other than the spammer randomizing colours. This one looks better than the black on cyan version, or any of the other geocities-esque variants. Loading images actually makes them look worse.
I’m also seeing a lot of spam that, from the design and structure of the mail, looks like it’s from the same spammer advertising printer ink and conspiracy theories coming from contact@barkboxdog.us.
This has been going on consistently for well over a year. While it isn’t being sent by BarkBox directly it is advertising BarkBox products and it is being paid for by BarkBox.
Badly run affiliate programmes like this one damage the brand. I wouldn’t be surprised if they damage delivery of legitimate mail sent by the brand owner – I know that my bayesian spam filters seem to put any mail mentioning barkbox into my spam folder, and they’re far less sophisticated than the ones used by large consumer ISPs.
I’ll do a tear-down of the spam on Monday and see if there’s any insight about how it all works and where it’s going wrong.
We mention RFCs quite a lot, both explicitly (RFC 6376 is the specification for DKIM) and implicitly (the 822.From aka bounce address aka return path).
And we have local copies of a bunch of them to make them easy to refer to (SMTP, MIME, Carrier Pigeons …).
They use quite a lot of jargon and implicit information and metadata that’s not really explained terribly clearly anywhere, rather picked up from experience using them.
But now Mark Nottingham has written a great intro “How to Read an RFC“.
It’s good. If you ever need to refer to RFCs you should go and read it.
A few weeks ago we took a drive down I5 to attend a service at Bakersfield National Cemetery. Amid the acres and acres of almond farms there were patches of black from recent grassfires. Typical but boring California landscape. Wildfires are a hugely destructive but continual threat in California. Growing up on the east coast, I never really understood wildfires. How can acres and acres and square miles just burn?
Having lived in California for almost as long as I lived on the east coast, I understand a bit better. In some ways, I have to. Even living right on the bay, there’s still some risk of fire. Like the grass fire a few miles from here across the street from the FB headquarters a few years ago. Further up the hills, there’s an even bigger risk of fire. Every driver can see the signs and precautions. Fields have plowed firebreaks around the edges. CAL FIRE posts signs alerting the public to the current fire risk status.
What do wildfires have to do with deliverability?
I associate wildfires and deliverability together because of a radio show I did a few years ago. It was pitched as a “showdown” between marketers and deliverability. I was the representative of deliverability. During the conversation, one of the marketers mentioned that deliverability people were too focused on the worst case scenario. That we spoke like we expected a fire to break out at any moment. His point was that deliverability spent too much time focused on what could happen and not enough time actually just letting marketers send mail.
His overall point was deliverability people should put out the fires, rather than trying to prevent them in the first place.
I thought about that conversation during the long drive down I5 the other day. I saw the firebreaks plowed into fields at the side of the road. And I saw the patches of blackness from fires reach along the highway where there were no firebreaks.
There are a group of marketers who really hate the entire concept of deliverability. Their point of view is that deliverability is hampering their ability to make money. I’ve even heard some of them assert they don’t care if 70% of their mail goes to the bulk folder. They should be allowed to send blasts of mail and deliverability shouldn’t tell them what they can do. Deliverability, so the complaint goes, is simply out to hurt marketers.
The only good deliverability is that which gets them unblocked when their behavior triggers IP based blocks. When the field is burning down, they’d like us to come spray water on it. And then go away and let them keep throwing lit cigarettes out their car windows.
But that’s not all that firefighting is about. Much of the work is preventing fires in the first place. In the US, a lot of that work is done through building codes. There are mandates like smoke detectors, fuel free spaces around dwellings, and sprinklers for some buildings. Monitoring local conditions and enforcing burn bans are also a large part of what the fire service does.
I like the fire fighter motif a lot. Much of what deliverability does is actually about preventing the block. ESPs have building code like standards for what mail is good and what is bad and what can be sent on their networks. Many of us publicly speak and educate about good practices and preventing blocks in the first place.
Fire prevention is about risk management and understanding how little things add up. Deliverability is similar. All the little things senders do to improve their deliverability adds up to a lower risk of fire. Yes, things like listbombing happen where even the best deliverability advice wouldn’t have prevented it. But, overall, deliverability wants to help senders get their mail in front of the people who can act on it. Some of that advice, though, takes the form of risk management and saying no.
An on the ball reader sent me a note today showing a bounce message indicating microsoft was rejecting mail due to a Spamhaus Blocklist Listing.
5.7.1 Client host [10.10.10.10] blocked using Spamhaus. To request removal from this list see http://www.spamhaus.org/lookup.lasso (S3130). [VE1EUR03FT043.eop-EUR03.prod.protection.outlook.com]
The IP in question is listed on the CSS, which means at a minimum Microsoft is using the SBL. I expect they’re actually using the ZEN list. ZEN provides a single lookup for 3 different lists: the SBL, XBL and PBL. The XBL is a list of virus infected machines and the PBL is a list of IPs that the IP owners state shouldn’t be sending email. Both of these lists are generally safe to use. If MS is using the SBL, it’s very likely they’re using the other two as well.
The intent of DMARC is to cause emails to silently vanish.
Ideally deploying DMARC would cause all malicious email that uses your domain in the From address, but which has absolutely nothing to with you to vanish, while still allowing all email you send, including mail that was sent through third parties or forwarded, to be delivered.
For some organizations you can get really close to that ideal. If you control (and know about) all the points from which email is sent, if your recipients are individuals with normal consumer or business mailboxes, their mailbox providers don’t do internal forwarding in a way that breaks DKIM before DMARC is checked and, most importantly, if your recipients are a demographic that doesn’t do anything unusual with their email – no vanity domain forwarding, no automated forwarding to other recipients, no alumni domain forwarding, no forwarding to their “real” mailbox on another provider – then DMARC may work well. As long as you follow all the best practices during the DMARC deployment process it’ll all be fine.
What, though, if you’re not in that situation? What if your recipients have been happily forwarding the mail you send to them to internal mailing lists and alternate accounts and so on for decades? And that forwarding is the sort that’s likely to break DKIM signatures as well as break SPF? And while everyone would advise you not to deploy DMARC p=reject, or at least to roll it out very slowly and carefully with a long monitoring period where you watch what happens with p-none, you have to deploy p=reject real soon now?
What can you do that’s least likely to break things, while still letting you say “We have deployed DMARC with p=reject” with a straight face?
- Make sure that every bit of mail you send is sent with both valid SPF and a valid DKIM signature for the domain you use in the From address, so both are DMARC-aligned
- Use “relaxed/relaxed” canonicalization (not “relaxed” canonicalization, as that’s quite different).
- Don’t do anything “clever” with your SPF or DKIM configuration. Use simple configuration that’s likely to be well understood by recipients. Very simple.
- DKIM sign a minimal subset of headers – e.g. “h=From:Subject:Date”. Definitely don’t sign Reply-To:, To: or Message-ID: headers, as they’re the most likely to be modified during forwarding. (From: is also likely to be modified – but if it is, it’s no longer going to trigger your DMARC policy so you don’t care).
- If you’re generating bulk email, make sure that it’s not only entirely valid but that there’s nothing in the structure of the email that might trigger an intermediate server to rewrite it. Make sure that the headers aren’t excessively long, and are wrapped in a normal manner. Make sure that the mail doesn’t have any long lines in it (quoted-printable encoding is a good way to ensure that). Make sure there aren’t any non-ascii characters in the headers or body; that everything is encoded appropriately.
- If possible, consider separating your mailstreams. Put all your supposedly “security critical” email on a DMARC p=reject domain, and offload your mail that’s not likely to be impersonated onto it’s own domain, one that isn’t covered by the DMARC p=reject diktat. Do everything right on that new domain, make sure it’s all sent cleanly and with DMARC-aligned authentication … just don’t publish a DMARC p=reject record for it.
- Monitor how DMARC is affecting your mail. Make sure you’re receiving all the aggregate and forensic reports you can, and also that your postmaster and customer support teams notify you of any issue that looks at all like mail going missing (or being rejected, or going to a spam folder – as some mailbox providers won’t follow recommended practice for DMARC failures and will route the mail to a spam folder instead).
- Monitor things for as long as you can with your DMARC set to p=none, and fix as much as you can identify via DMARC forensic reports before switching it to p=reject.
- Track where mail that’s being impacted is being delivered to. If there’s low hanging fruit, maybe reach out to the forwarder and work with them to fix things so that their forwarding doesn’t break your DKIM signature. As a last resort, adding the forwarders IP address to your SPF record will allow DMARC to pass (at the cost of removing any pretense of DMARC protection for those recipients).
Have a relaxing picture of a forest. You’re going to need it.
But, unfortunately, some senders don’t actually think unsubscribe means stop sending mail.
Today, for instance, the nice folks at The Container Store sent me an email with an “important update to my POP! account”
Yes, that’s an address I gave them. But I don’t have any record of setting up an account. I was on their mailing list for all of 4 emails back in November 2016 before unsubscribing. But, they’ve decided they can email me despite my unsubscribe request.
They’ve cloaked this as an “Important Account Update” about some account I don’t have. In fact, when I go to their website and try and see what this oh so important account is about they tell me:
I understand legitimate account notifications might be an acceptable excuse to send mail even after the recipient opted out. This, however, was done extremely poorly. There is no record of the account that they are sending me information about. Neither the company nor I have any record of this account of mine.
At a minimum the emails should have only be sent to the folks that actually had an account. But, they weren’t.
I also have some issues with a company requiring recipients to accept email in order to continue using reward points. As a recipient, if I wanted what they were offering I might go ahead and continue receiving emails. But, I might not. It would all depend on how aggressive their email program is and how good the rewards are. As a deliverability consultant, this strikes me as a great way to create a mailing list full of unengaged users. Unengaged users lead to spam foldering and eventual failure of an email marketing program.
Whatever some executives think, and having been in this industry for a decade and I half I’m sure this is coming from the top down, this is not a good way to build an email program. You really can’t force folks to accept your email. ISPs are too protective of their users to make that a viable strategy.
In the deliverability space we talk about permission and consent a lot. All too often, though, consent is taken not given. Marketers and senders assume they have permission to send email, while the recipient is left expecting no email.
There are different ways that companies assume permission. A favorite is to hide the permission deep in the terms and conditions or in the privacy policy. This is problematic on a number of different levels. In some cases, the privacy policy and the terms and conditions policies contradict each other. One will say they can send email, the other says they won’t.
Other forms of taking permission include scanning badges at conferences and uploading address books to bulk sending programs. Neither of these things are actually permission. Just because someone corresponds with an employee does not mean they are giving permission to be added to mailing lists.
Modern laws are attempting to address this. Both CASL and GDPR make it clear that senders can’t simply assume they have permission to send mail. Permission must be explicitly granted and the terms of the permission must be clear. The new California privacy laws are also trying to make consent explicit.
Overall, laws requiring explicit permission are a direct result of too many marketers and senders assuming consent. The regulations weren’t created out of nothing, they’re a response to ongoing abuses by the marketing industry. The marketing industry had the ability to head this off by acting reasonably, but self regulation wasn’t on the table.
As I’m writing this, I’m watching Deputy Atty General Rod Rosenstein discuss the indictments of 12 Russian military officers for hacking activities during the 2016 election cycle. One of the methods used to gain access to systems was spearphishing.
I think most of us know what phishing is, sending lots of emails to a wide range of people in an attempt to collect some credentials. These credentials are usually passwords to bank or email accounts, but can also be things like amazon or other accounts.
Spearphishing is an attempt to collect credentials from a specific person. The net isn’t thrown wide, to collect any credentials, rather individuals are targeted and researched. These attacks are planned. The targets are carefully researched and observed. The emails are crafted specifically for that target. If one set of emails doesn’t work, then they try again.
In terms of email marketing and deliverability, phishing is something detectable by many anti-spam filters. They’re sent in bulk, and they all look similar or identical to the filters. Spearphising isn’t as simple to detect with standard tools. What many organizations have done is try and combat this with warnings in the client. Like this one from gmail:
Security is becoming a bigger and bigger part of email filtering. I expect that as filters start addressing security more, we’ll see increased warnings like the above.
What can senders do?
- Even if you can’t publish DMARC records make sure your domains are aligned.
- Expect and plan for filters crawling links at delivery time.
- Limit the number of redirects for any one click. (one is fine, 2 or 3 is probably OK, 7 or 8 is probably too much).
This is another example of the outside factors that are driving filtering and affecting email marketing.
Recent Comments