[Mailman-Developers] Save the world from spam

[John Morton]

On Friday 22 February 2002 14:36, Chuq Von Rospach wrote:
> On 2/21/02 5:25 PM, "John Morton" <jwm@plain.co.nz> wrote:
> >> 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!
>
> Um, John? I've been doing that for months. It's a standard tactic I use to
> test for archive harvests. No offense, but given I'd already thought of the
> "subscribe and harvest" attack, wouldn't you think I also would have looked
> for ways to detect it?

Excellent. Would you mind publishing an analysis so we can start making some 
informed decisions as to what methods are effective?

> I just don't like to talk about it. One has to think the harvesters are
> listening. I don't like giving away too many secrets -- but at the same
> time, it's something we have ot share ideas and concepts over...

Wah! Spammers aren't the NSA/Red Menace/Grey Aliens. I think we can and 
should be discussing what they're acutally up to if we want to find good 
methods of dealing with it. Don't get me started on full disclosure :-)

> > 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.
>
> I won't argue. I expect Jay will pop up shortly and do it for me. Which is,
> I think, the point. Just because you aren't too sensitive to the mail
> doesn't mean others aren't -- so we have to keep all of the views in mind.
> And this is a case where I actually side more on your view, but still
> understand the need to manage this for those that don't have my tolerance
> level.

As a list admin, I'd like to inform my subscribers about their level of 
exposure, and empower them to decide whether there email address will appear 
in the archives, and how. I'd also like to keep the signal to noise ratio on
the admin address in a tolerable state without running too great a risk of 
throwing the baby out with the bathwater by dropping too many legitimate crys 
for help along with the processed pig product. 

I'd like it if mailman would help me out with these things, but I don't want 
to _have_ to use ADA/text only browser busting jpeg addresses and reverse 
turing tests, and I don't want to have to use web form access to addresses in 
the archive as I won't trust that code until a lot of security geeks have 
looked it over.


> Only if you don't change them. Making them standard might not be a good
> idea, once they're hidden behind contact forms.

Check. Add that to the admin form wishlist.

> > The problem with obscurity as a security tool is that it's not reliable.
>
> It only works until it fails, and then you can't fix it. And I've found it
> invariably fails at 10PM on a Friday night, when you're about to leave for
> the weekend -- unless it's 2PM on a Thursday with a Friday deadline.

As I said, obscurity works if you can replace one instance of compromised 
obscurity with another one fairly quickly. Works for passwords, and it can 
work well enough for this application, too.

> > Obscurity is useful. In our case, it's the only prevention tool we have.
>
> I'm not sure obscurity is the right word. Most of what we're talking about
> is more of a cloaking effort.

That's because email addresses aren't secrets. If you can think of a better 
method than address mangling or hiding behind web forms, do tell. Personally, 
I'm willing to consider those good enough for the time being.

John