There are some very simple solutions to the problem of email harvesting.
The first is to whitelist all mail. Anything not on the whitelist (be it list membership, or whatever) is responded to with an invitation to fill in a web based form to join the whitelist, the mail is held in abeyance until the whitelist is joined. You can hide the whitelist join function behind a POST operation, but can also do a reverse turing test of the 'type what you read in the image above' type to verify that it's a human joining the list.
-----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of John Morton Sent: Monday, 18 February 2002 00:25 To: Chuq Von Rospach Cc: email@example.com Subject: Re: [Mailman-Developers] Interesting study -- spam on posted addresses...
On Monday 18 February 2002 17:56, Chuq Von Rospach wrote:
On 2/17/02 8:39 PM, "John Morton" firstname.lastname@example.org wrote:
If they can set up admin specific accounts that redirect to /dev/null, then they can set up procmail to drop HTML mail, and say they're doing so anywhere they're advertising the admin email address. That would filter 90% of the spam they're likely to recieve
for a start.
And a bunch of legitimate mail, since more and more users are using HTML, and more and more systems are set up to send it by default. Not a solution, unless you primarily admin to geeks.
It's better than > /dev/null :-). Let's face it - if you're going to publish an admin address to help the lowest common denominator of netizen, then you can't munge it, so it will get spam. Mailman doesn't provide filtering for email accounts, nor should it. So the best you can do is advise admins of good filtering software, and best practice ways of using it. Droping html mail happens to be one practice that works pretty well for a given type of list membership.
Something that mailman can help with, though - assistance in filtering based on whether the sender is joined to a list that the admin account is tied to. Just a simple boolean is/isn't on the list
should be enough; leave the policy to the delivery agent/user.
And how odes that does the "I'm trying to subscribe and can't make it work!"
It doesn't. But you can put all the requests from list members into another folder, or give them a higher priority. It all helps. If you need to prioritize subscription problems then you could use a feedback form, and maybe Mailman should provide one.
"My stupid IS department changed my address again and I need help!" problems?
I never understood why mailman wasn't changed to allow users to change there own addresses years ago. Being able to add valid receiving addresses would help, too. That is also something mailman can help with.
Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers