Wandering Thoughts archives

2014-05-31

Wnen trying to unsubscribe from spam can be not completely crazy

For reasons beyond the scope of this entry, I've started running a little 'sinkhole' SMTP server to collect email for what is essentially a disused set of old addresses of mine. The server takes in everything, logs the messages to disk, and then tells the senders that they weren't delivered; later, I can go through the logged messages to see if anything interesting has shown up. In the process of doing this I've noticed that a surprising amount of the spam comes with List-Unsubscribe headers with URLs. So I've been using some of them to see what happens (especially when I recognize the sender as a long term repeat offender).

Normally it's an article of faith that you should never, ever use a spammer's unsubscribe procedure. Doing so only confirms that your address is live and perhaps helps the spammer, reducing the load on their systems and so on. I'm not sure that what I'm doing here is exactly sensible (although it makes for an interesting experiment), but I don't think it's completely crazy.

The big difference between my situation and the normal situation is that the addresses I am 'unsubscribing' are already dead addresses as far as I'm concerned. They basically no longer get valid email (and some of them don't even exist) so any increase in the amount of spam coming to them is immaterial; it's just more grist for the sinkhole to reject. Also, these addresses have been aggressively defended for what is now years and spammers have been trying to bang away at them for years. It's clear that the repeat spammers I can recognize simply don't notice or don't care about any extra load on their mail sending systems that I've been creating with prior tactics like blackholing SMTP traffic from their IPs in the firewall. If they did they would have removed such unresponsive addresses by now, often years ago.

At one level I don't care about the load on my sinkhole, but at another level I do. I'm running the sinkhole to collect interesting new things, and yet more spam from some usual suspect is completely uninteresting. If I can make it go away by unsubscribing rather than making the sinkhole's environment more complicated, so much the better for my real goals.

Or at least that's my thinking so far. I may change my mind later and stop doing this.

(But I'd also find it very interesting if unsubscribing actually seemed to increase the spam from the usual suspects, or even increased it. Seeing if this will happen is one reason I'm bothering with the experiment at all.)

UnsubscribeWhy written at 23:15:55; Add Comment

2014-05-28

Yahoo Groups has a bad spam problem and they don't care

For a while, one of the things I've noticed any time I look at our mail system is that we seem to be getting spam from Yahoo Groups. Today I decided to look at the magnitude of that spam. I'm afraid that the results are really terrible.

Over the past roughly 30 days, our main spam filter has seen 29,545 email messages with an envelope origin address at returns.groups.yahoo.com. 28,869 of them has been scored as pretty definitely spam; that's 97.7% of the messages. That's what you could call not very good, and in fact it makes Yahoo Groups the single largest envelope origin domain on all of the spam we've received over that time span.

(Interestingly the second highest is the null sender address, but it's used by less than a third as many messages as come from Yahoo Groups.)

As they say, 'but wait it gets worse'. We also have an optional DATA-time rejection based on spam scoring. This system logs not just basic envelope information but also the Subject: headers from rejected messages, which means that I can look at what they are for rejected Yahoo Groups messages. Those subject lines are, well, interesting. Here, let me show you a random sample of what I saw when I looked:

Subject: [PMX:SPAM] Hot Angelina Jolie Sex Scandal
Subject: [PMX:SPAM] Do You Want To Get Closer To The Next Love?
Subject: [PMX:SPAM] Look For Horny Chicks Near Your Home
Subject: [PMX:SPAM] nice hot girl sex on the office desk
Subject: [PMX:SPAM] Absolutely Free Cyber Casual Affaires
Subject: [PMX:SPAM] Do You Want To Have A Chat With Hot Cybersingles?

I think you get the point. By the way, this excludes many, many subject lines that contain various sorts of sex language, partly because I decided that I didn't want Wandering Thoughts to turn up internet searches for those words.

(We log the Subject: line for because it gets annotated by the spam scoring system and thus gives us some additional data on why the system rejected a message if we ever need it.)

All of this is clearly sex spam. And based on both the subject lines and on the fact that it was detected by our spam system (which I'm sure is not state of the art for major online email providers), this should be stuff that Yahoo is more than capable of detecting on the way out of their systems. Yet they don't. The spam flows unimpeded and has been flowing for what I believe is now a very long time (because I've been casually noticing this stuff from Yahoo Groups for years now).

One corollary is that you almost certainly want to get any remaining legitimate groups off of Yahoo Groups, if you're involved with any. The odds are increasing that places will reject all email from Yahoo Groups (or blackball the emitting IP addresses, although Yahoo may not use dedicated IPs for Groups).

(See also this early 2012 data on top domains on spam messages and the discussion of Yahoo Groups there.)

YahooGroupsSpam written at 00:34:58; Add Comment

2014-05-14

Modern mail forwarding is leaky

As I noted in my entry on how DMARC would affect us, modern mail forwarding is now leaky in practice. In the old days, if you forwarded your mail from address A to address B you could be reasonably sure that everything that made it to address A would also make it to address B. In the modern world this is no longer necessarily so; it's quite likely that some amount of the mail that was accepted by the mail system for address A will not get accepted by address B. This lost email has leaked out of the system (and the senders may or may not ever find out about it).

Of course there are all sorts of things that will cause mail to leak, and not all of them are bad. Certainly some of the leaked email will be spam that mail system B does a better job of recognizing than mail system A (which is especially likely when mail system B is a lot larger and more sophisticated than mail system A). In a world with an increasing amount of DMARC 'reject' policies, some of it may be email that is considered illegitimate by the origin domain's policy (whether or not it actually is illegitimate). But it can also be email that is mis-classified as bad by mail system B, or email that is simply caught up as collateral damage because mail system B sees too much bad stuff coming from mail system A.

(There are various ways for the collateral damage to happen beyond the straightforward.)

Naturally it's somewhat hard to measure how much nominal leakage there is and very hard to measure how much leakage of legitimate email there is (at least without doing intrusive and privacy violating monitoring of bounces and their content).

Of course, leaky forwarding is not new. Forwarding has been slowly becoming leakier and leakier over the years as spam and other bad stuff became an increasingly large part of email and as places got very varied levels of anti-spam filtering. But I'm not certain that our users understand that and I'm pretty certain that our documentation about how to set up forwarding doesn't contain any real discussion of the possibilities (and I suspect that that should change).

PS: I'm implicitly ignoring in this anyone who wants to forward all of their email, spam included, from mail system A to mail system B. That just doesn't work at all these days; there will be a firehose of 'leakage' as mail system B laughs at your spam.

ModernForwardingIsLeaky written at 01:59:53; Add Comment

By day for May 2014: 14 28 31; before May; after May.

Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.