Spam Catchers Block Latest Crypto-Gram

An anonymous reader writes "Bruce Schneier sent out a note about SpamAssassin and possibly other spam filters blocking his excellent Crypto-Gram newsletter. Fortunately you can get it here (early no less!)." Schneier's email reads, in part "Tomorrow I will be sending out the February CRYPTO-GRAM, as I do on the 15th of every month. In the process of creating this month's Crypto-Gram, I discovered that SpamAssassin thinks that this issue is spam, probably because of certain links and descriptions of scams in the text. I have anecdotal evidence that other spam filters block Crypto-Gram as well. ... I'd apologize for the inconvenience, but I'm not sure what I could do to make it less so -- I don't intend to alter my content to accommodate spam filters."

Comments

White List

[SealBeater]

That's easy to fix, add the crytogram address to a whitelist. Every spam
filtering software I've ever run, including spamassasin (which I like a great
deal) has a whitelist option. If you're running some kind of filtering
software, it behooves you to keep an eye on what it's blocking, hence, I am
sure that people are aware of it and have adjusted their software accordingly.

SealBeater

The problem with filters

[markfletcher]

This illustrates one of the big problems with filters. They will never be perfect, spammers are always adjusting to them (even the Bayesian ones), and the way many are implemented, they make email unreliable (by deleting suspected spam messages and not bouncing them). Blocking untrusted servers by IP address avoids these issues.

obPlug: This is why I created Trustic.

The problem with content filtering

[Leeji]

This is exactly the problem with most content filtering approaches.

It is very hard to discern the difference between talk about sex, spam, viruses, etc and talk from sex, spam, viruses, etc. Newsletter authors go as far as writing "v*rus" and "sl*mmer" so that pitiful content filtering blocks don't trash them.

It gets even worse for email lists that use inline text ads. The ads alone would constitute spam, but they're nestled within several paragraphs of high-quality discussion.

The problem is that content filtering approaches usually only analyze the "spamminess" of a piece. They usually don't analyze the "goodness" of a piece. So if I put "hot teens go crazy for debt-free viagra while earning $$$ from home" in the middle of some fine Shakespeare, that will get flagged as spam.

The new "bayesian" approaches are finally dealing with this problem -- something can look an awful lot like spam, but it will be saved if it looks even more like legitimate email.

In this case, spam doesn't generally run for 21 pages with words like "cryptography," and "full disclosure."

Re:The problem with content filtering

[1u3hr]

In this case, spam doesn't generally run for 21 pages with words like "cryptography," and "full disclosure."

The problem with that is that if you score mail by the percentage of spam, rather than the absolute amount, the obvious response by spammers is to ADD 21 pages cribbed from a crypto newsletter to the end of their penis-enlarging spam. Maybe even fake the headers to make it look like it came from a respected source.

SPEWS

[some1somewhere]

At least he is only on Spamassassin which tends to be run on the client-side, so statistically less people would not see the newsletter. If he were on the SPEWS's blocklist, he'd never get out!

http://www.antispews.org/ the SPEWS fansite (not!)

Personally I see less problem with client-side blocking, as there is less chance that any 2 people would use exactly the same combination of blocklisting/priorities/etc. Plus, programs like Spamassassin use quite a lot of processing power, so large mail servers (eg. for an ISP) would need significant additional resources to handle this. Thus it is best to move such individualized and resource-intensive applications to the client-side anyway.

YMMV.

Re:SPEWS

[Skapare]

If he were on the SPEWS's blocklist, he'd never get out!

And this is why the SPEWS blocklist is so effective and so good. If he were on it, then that would mean that he and/or his network fell into one of the following categories:

• Is a spammer
• Is an ISP harboring a spammer (or an upstream ISP thereof)
• Is a customer of an ISP harboring a spammer

Because spam causes abuse to email servers, even when the mail is refused either for reasons of an IP based blocklist, or for content filtering ... abuse in the form of higher costs for the server operators and recipients ... the proper goal is to get the spammer not just blocked from being able to get mail into your mailbox, but fully disconnected from the internet to prevent these kinds of costly abuses in the future. And since only the ISP hosting them can actually disconnect them, it will be the job of that ISP to do so. Most ISPs will when they realize the situation. A few ISPs refuse to, and that's when it comes time to put pressure on the ISP by expanding the blocking of the ISP's network, forcing them to consider that their legitimate customers will be leaving if they do not disconnect the spammer. SPEWS gradually expands listings so that the point where the ISP finally understands this can be reached with the minimum of so called collateral damage (which is not really, because these are customers who are paying money to an ISP which harbors spammers, so they share in the guilt).

Bruce Schneier's mail server happens to not be listed by SPEWS. So it can be said that he is not a spammer, is not running an ISP that harbors spammers, and is not using an ISP that harbors spammers. That is a good thing and shows that SPEWS not only works, but works better than content based filtering.

Content based filtering also is a direct violation of the principles of the US First Amendment right to free speech (although the actual amendment only applies to restrictions imposed by the government and does not apply to private businesses in most cases, if not all). Infringement of free speech happens when the decision is based on what the content is. When restrictions are not affected by the content, then such restrictions are considered fair since any content can be passed when the behaviour that evoked the restrictions is not done. And the whole spam issue is about behaviour, not content. The bad behaviour is the act of inappropriately choosing multiple recipients for sending the message ... e.g. unsolicited bulk email (UBE).

Of course on your own mail server you have a right to use whatever methods you deem appropriate based on how you want to balance your costs, the quality of your service to your customers, and how much cost you want to pass on to your customers. Obviously you have to be in contractual agreement (possibly implied) with your customers about what methods are chosen. If you only offer one kind of service and your customer does not want that kind, by being properly aware of what you do offer, they can go elsewhere. Or you can offer a diversity of services the customer can choose from (e.g. a customer control panel to control the methods of spam filtering for their email accounts). So the choice of what method to use to block spam is strictly a relationship between a provider and its own customer.

In the case of a network owned by a business only to serve that business function, then it's simply the commercial version of "my server, my rules".

Re:This is a non-issue....

[Elwood P Dowd]

Thank you. Also, if all the bayesian filtering advocates are right, then the users should be able to mark the Cryptogram as non-spam, and the filter should adapt. More to your point, though, is that lack of spam-filtering software can cause false-positives in your own personal, analog, spam filtering algorithm. Many of my users have deleted important, non-spam, automated emails manually because they thought it was spam. Sometimes, the machine might have less false positives than they would.

Huh. It occurs to me that it seems like some spam filters might pass a turing test if the only output is their spam judgment. Wow. The future is now, dude.

Re:This is a non-issue....

[1u3hr]

Either you choose to run a spam filtering software and live with thoose limitations or don't ...

Except if it's done upstream from you, perhaps even without your knowledge (eg a few months ago it was found that Mac.com was aggressively filtering, with a lot of false positives).

A Simple question...

[Pathwalker]

Am I the only one that has all of the mailing lists I subscribe to bypass SpamAssassin?

For each mailing list I subscribe to, I use a special address suffix just for that list, that bypasses all of my spam checks (including SpamAssassin ), and just goes right into the mailbox that I use for that mailing list.

No problems with false positives, and it saves me the overhead or running SpamAssassin on every incoming message from a busy list.

it just seems like common sense, no one should have a problem with SpamAssassin misclassifying incoming newsletters if they just think about how they organize their email.

Re:In principle, yes, in practice, no.

[BlueUnderwear]

Then it would not be an encryption but a signature.

You are right that it would not be encryption in the sense that it doesn't protect privacy of the message (indeed, in order to read the message, you only need Bruce's public key, which is indeed, uhmm, public...).

However, it would still fulfull the goal of evading spamassassin, because, as far as I know, spam assassin is not yet smart enough to figure out that the message has been "encrypted" with Bruce's private key, and to fetch the public key from the Bruce's webserver to decrypt it.

But then again, rot13 would probably be enough to evade spamassassin too... as long as you don't mispell inventive as ivntenive that is...