- 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: > - I strongly believe now email commands should also include a password > reminder/recovery feature, so that in cases like ours users can still get > their passwords and unsubscribe via email. Currently a password can only be > 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: > - 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 > themselves... > ...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 > [EMAIL PROTECTED] > > > _______________________________________________ > Mailman-Developers mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/mailman-developers _______________________________________________ Mailman-Developers mailing list [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/mailman-developers
