[Mailman-Developers] bugtraq submission warning: email address
Chuq Von Rospach
chuqui at plaidworks.com
Thu Nov 27 12:17:33 EST 2003
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).
More information about the Mailman-Developers