[Mailman-Developers] bugtraq submission warning: email address harvesting exploit

[Chuq Von Rospach]

On Nov 27, 2003, at 9:08 AM, Terri Oda wrote:

> On Tue, Nov 25, 2003 at 11:07:39AM -0800, Chuq Von Rospach wrote:
>> Fails ADA and accessibility requirements badly. I'd argue against any
>> solution that fails such basic needs without any real way to fix it.
>
> What about reverse turing tests that aren't graphics-based?

if it can be made accessible, I have no problem with it. But I think 
it's solving the wrong problem, because the data is still accessible to 
a motivated person. you're not fixing the issue, simply raising the bar 
and hoping they give up. It won't stop the spammer who hires a dozen 
temps to surf web sites and authenticate their bots through, right?

So the REAL answer, IMHO, is to not make that information available. 
Cloak it programattically. If you want to have an authenticated mode 
for subscribers to keep it uncloaked, that's fine by me. But the public 
archives should simply recognize significant pieces of information and 
elide them from the output. That way, no matter what a spammer or other 
nasty person does, they can't get the information. It's not there.

my definition of significant pieces of information: email addresses, 
phone numbers, social security nubmers (and if there are global 
equivalents to this US number, those, too). Simply replace them in the 
text with [[email address omitted]] as you deliver the archive. Then 
you stop playing this arms war with spambots completely, by removing 
the target they're after. No need to, two years from now, rip out the 
work you did and come up with a new temporary fix because spammers got 
around to implementing new OCR techniques.

Remember challenge/response? When everyone thought it was the solution 
to all of our problems? Took the spammers under six weeks to crack it 
once they decided to try. (answer: send spam as being "From:" you, 
"To:" you. Most C/R systems have the user's email address whitelisted. 
end of story.

>> Better is to simply teach the archives not to distribute sensitive
>> information at all. And a lot easier to implement, actually.
>
> So, is anyone working on this *within* pipermail?

that would be the answer, or throw it out (I'm not a huge fan of 
pipermail; it's only advantage to mailman is it's written in Python) 
and do something else. Or leave pipermail alone, and write a CGI that 
all archives exit through that does the filtering, which is IMHO, how 
you ought to do it. That way, you can authenticate via that CGI to a 
level of access, change the filtering on the fly, and leave the 
archives unedited (as I think they ought to be).