• If all the SPAM is coming from one server, block the server at the SMTP level.
• Spammers using Mailman to send out spam is a Spam problem, not a Mailman problem.
• Spammers might not actually be using Mailman, just forging the appearance of mail. I think this is far more likely. While all of spamassassin's "list removal" tests happens to trigger a positive score, I would not be at all surprised if SA alternatives, or Bayesian filters would do the opposite.
• Mailman is Open Source. It would be infinitely easier for a Spammer to remove any/all password recovery code then it would be for the Mailman developers to expand on it.
• If you do happen to 'crack' this spammers install of Mailman (possibly by an "inverse trojan": that of "fixing" Mailman) the spammer could trivially use an alternate mailing list management system. Or just not upgrade. Or upgrade and 'break' the new version.

To repeat, I find it unlikely that a spammer is actually using Mailman. It just doesn't make any sense. Given the design goals/limitations, while not incompatible with spamming, Mailman a poor choice. There are vastly superior, and as easy to find (or stumble upon), alternatives. If the spammer is using Mailman, then they are using a UNIX MTA; all that I know of have built in alias/list expansion. Why would they tack on what is an extremely complex alias/list expansion self management system?

On Thu, 2003-12-25 at 17:32, Roberto Perez wrote:

Hi,

I hope I can get some insights into this problem.

I've been using Mailman in our university to administer a number of lists, and the web interface has worked well so far for us. However, in the recent weeks we have learned a spammer has subscribed many of our email accounts to his own mailman system (on a server outside the US), and has disabled the web interface. This means no one can get a reminder of their passwords to unsubscribe via email (since when an administrator subscribes users no password is sent).

As it is now, Mailman is being used to keep those accounts "captive" and bombard them with unsolicited email. So the purpose of my email is twofold:

** Development: their passwords and unsubscribe via email. Currently a password can only be

• I strongly believe now email commands should also include a password reminder/recovery feature, so that in cases like ours users can still get

recovered via the web interface (which a spammer can disable).

• I also think when the administrator enrolls users, the passwords should be sent as a default, with no possibility of disabling this feature. This would cut down on misuse of Mailman as the one described above.

** Management: themselves...

• This is a generic question to all managers: if
• a Mailman list does not offer a web interface to recover a password to unsubscribe,
• the manager does not reply to unsubscription messages,
• the bounce utility has been disabled (so sending fake "Returned mail" messages does not trigger unsubscription),
• the monthly password reminder has been disabled,
• the Mailman server is outside the US (so reporting to the FCC is useless),
• and the list is being used to bombard subscribers who did not subscribe

...how else could unsubscription be achieved in Mailman? I know that users could put filters, but I'd like for the messages to stop instead of having to put patches here and there on each user's machine...

Thanks in advance for any pointers/ideas/suggestion you may have.

Roberto Perez rgpg@technologist.com

---

Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers