mailman responds to mail with no valid command

[Jozsef Kadlecsik]

Mailman at the -request aliases respond to any mail sent to the addresses, even if the mail did not contain any valid command. That can easily be abused by spammers: they send mail with forged from address to a -request alias, and mailman "bounces" it back to the forged sender. Firstly, it is some kind of annoying backscatter which should be stopped, secondly if the forged address happens to be a spamtrap one (or the backscatter is reported), it results the mailman server landed on a blacklist.

It happened two times with our listserver and SpamCop.

The attached patch introduces the discard_email_without_command list parameter: if it is true (default) then mailman ignores any mail which does not contain a valid command. I left out the Gui part because could not figure out a clean solution: even as a per mailing list setting I think the site admin should decide which (internal-only) mailing lists do not need the flag and which (externally visible) mailing lists must be protected.

Please consider applying: it's really bad to be blocked by an RBL.

[Mark Sapiro (msapiro)]

Thanks for the report and suggested patch. This is only part of the larger backscatter from Mailman issue which will be addressed in Mailman 2.2. Your patch is helpful for this.

I'm leaning towards making all these thing controlled by site (mm_cfg.py) rather that list settings because ultimately they affect the entire mail server, not just a list or lists. Thus, as you understand, they should be controlled by a site admin, not a list owner.

If some of these settings actually need to be list settings (something I haven't gotten to yet), perhaps a compromise such as leaving them out of the GUI and requiring the non-default to be set by config_list or withlist is appropriate.

Do you really have a need for this to be a list rather than a site setting?

[Jozsef Kadlecsik (kadlec-launchpad)]

I can think of two other possible backscatter issues of Mailman: forged non-susbcriber E-mail sent to the -subscribe aliases - this could easily be handled in a few plus lines in my patch. Or forged non-subscriber E-mail sent to moderated lists - the reply E-mail about the moderation should be suppressed as well.

Is there any other backscatter issue?

I agree completely that no list owner should be able to override these settings. My patch follows exactly what you write about controlling it: there's no Gui, the site default can be overridden by the site admin using config_list only. :-)

Actually we haven't got a mailing list which is internal-only. But I suppose there are sites which have got both kind of lists (public/private) and would want to disable these settings for their private lists for
whatever reason.

[Mark Sapiro (msapiro)]

I am implementing this differently from the patch. It will be a site option, not a list setting. The implementation is not a complete solution to the problem as it doesn't address mail to the -join, -leave, -subscribe or -unsubscribe addresses as mail to these doesn't contain commands. It does check that mail to -confirm does contain a token (To: matches VERP_CONFIRM_REGEXP), but not whether the token is valid.

I am also implementing another option to not include any 'spam' payload in the response to email commands which will help in some cases, but there is still a problem with From: containing a spamtrap address.