[Mailman-Developers] Interesting study -- spam on postedaddresses...

[John Morton]

On Friday 22 February 2002 11:20, Chuq Von Rospach wrote:
> On 2/21/02 2:00 PM, "John Morton" <jwm@plain.co.nz> wrote:
> > I think we're really getting into wild speculation territory here. No one
> > will bother hacking the code to automatically get new free mail accounts
> > [...]
>
> Nobody has bothered to do this YET. That we know of. But the spamhacks are
> evolving rapidly. 

Well, let's find out shall we? Set up a honeypot private list containing a
collection of free mail accounts, then cycle through the account every week
checking for spam and making some postings to keep the traffic up. Enough 
with the armchair anthropology, already!

> More rapidly than the anti-spam hacks in many ways. I
> sure wouldn't depend on them never doing this.

I agree. That's because we're in an arms race here. Email harvesters are 
probably evolving faster than the countermeasures because of the tendency to 
deploy one countermeasure and forget about it. 

> I'm not sure what we'd do if
> they did, either, but some aspects of it have happened to me in small ways,
> just not from the major spamhacks.

So basically you need to deploy a countermeasure, monitor it's effectiveness, 
and deploy another when it fails. Repeat for as long as you consider it 
important, or can tolerate not resorting to private archives, and 
establishing better trust relationships with the subscribers.

> Fact is, if they want your subscribers, they can get them. Or more
> correctly, your subscribers that post -- but if everyone lurks in fear, why
> hav a mail list? 

I think we all need to take a deep breath and say 'It's only junkmail'. 
They're not spending up large on your credit card or pouring sugar into your 
gas tank. 

> The question is, what can we do to make it as tough as we
> can for the spammers, without screwing it up for us (as admins) or our list
> users. If only because the harder we make it for them to hack us, they more
> likely they'll go somewhere else that's easier to crack...

Right. So let's go with contact forms for list admins, and slashdot style, 
per user configurable address mangling for the archives. Let's do a little 
research into the ongoing effectiveness of these methods, too, so we know 
when it's time to implement something more expensive.

> On the other hand, if Mailman does become the de-factor mail list standard,
> or one of a couple of key list servers, you can bet the spam ahcks will
> focus on it, because if they can crack the code, they can crack a LOT of
> lists really fast. So we have the potential to become a target of our
> success, and we should be aware of that.

It's probably one of the top three or four already. Do listserv and majordomo 
admins have a major spam problem? 

The two above techniques will work fine. If I, as a list subscriber feel that 
the signal to noise ratio is dropping, I can change my address mangling 
scheme. Hiding the otherwise web published list admin address behind a form
should just about protect it by that vector for all time as it will just 
never be worthwhile hitting a collection of forms when you can get vast lists 
of addresses elsewhere.

(of course you have to publish the mailing list address, so you can deduce 
the admin address from that...:-)

> But what happens when other groups get smart too, and clean up the low
> hanging fruit? Depending on that to protect us is a false security,
> basically no better than the old security-by-obscurity issue. Given port
> scanners and the like, there IS no obscurity from the crackers any more.

The problem with obscurity as a security tool is that it's not reliable. You 
may as well assume that one day your secret will be out, so the decision as 
to where and how to deploy it needs to be made based on the cost of 
obscuring, the cost of having the information revealed, the cost of 
reimplementing the system to replace the obscured part, and the size of the 
window of opportunity created before you can fix the problem.

Passwords, passphrases, keys and so forth are all examples of security 
through obscurity. They work because it's very easy to replace them; they 
work most effectively in systems that are good at detecting that they've been
compromised. Striping identity strings from network daemons is another 
security through obscurity technique. No one would rely on it to protect 
them, but it does make the job harder for attackers and easier for the 
defenders - they have to try a lot more things to detect what software is 
behind the port, or just brute force it with known attacks, greatly 
increasing the detection and response time available to defenders.

Obscurity is useful. In our case, it's the only prevention tool we have.
Email addresses are not secrets, but we still want to protect them from the 
bad guys while making them available to the good guys. We will never solve 
this problem. Even if you made all the subscribers sign a contract promising 
not reveal the addresses of the list membership to non-subscribers, and had 
reason to trust that they where not spammers. Someone could always go over to 
the dark side. An outlook virus could alway be used as the spam vector. And 
so on. 

The best we can do here is implement something simple now that gets the job 
done, and continuously test it to see if it's still good enough. When it's 
not, we build another countermeasure. 

John