On 19 Oct 2006, at 11:47, Ian Eiloart wrote: > --On 19 October 2006 10:35:37 +0900 [EMAIL PROTECTED] wrote: > >> Giuliano Gavazzi writes: >> >> > I have then noticed that the confirm address (listname-confirm >> > [EMAIL PROTECTED]) and the request address ([EMAIL PROTECTED]) act as >> > mirrors to the alleged envelope sender, sending back the whole >> email >> > after the parsed commands. >> >> This kind of thing has been mentioned, I think, in respect of bounce >> messages. >> >> I think the real solution has to be to send only generated text when >> that will do. In case of a problem the original message should be >> stored (and queued for deletion after the usual period for expiration >> of a confirmation), and a reply generated containing an error >> message, >> and the URL of the original message for diagnostic purposes. >> > > Of course, this is a kind of open relay. If you can get email > through to the listname-request address, then you can get Mailman > to send email to any address that you like. I hope that's not true > of listname-confirm… Oh, but it is. If it sees an unrecognised > request, it will respond in the belief that it's an expired request. >
I think it is actually more general. Even a valid confirm token will reflect (relay) mail to anyone. > I have no real information on how often those addresses are really > used, but I suspect that most list interaction is through the web > these days. Is it possible to turn off listname-request for the > site? And, perhaps, to use a much longer expiry time (months rather > than days), and ignore or moderated unrecognised requests. Better > would be some opportunity to reject them early, so the MTA has a > chance of rejecting the incoming email. Turning off listname-request (and mailman-request and the confirm addresses too!) for a site is not difficult, just blacklist incoming mail to those addresses and change the text of the relevant messages and pages to reflect that. The "confirm" case is indeed a spiky problem. One could easily check the token against the pending database (one could do it from the MTA, exim could easily do it) but that would not stop a spammer getting valid tokens for new spam runs. The stricter check that would validate a token against the envelope sender would avoid this situation, but make the subscription process less tolerant, as one could subscribe an address that is an alias, and reply to the confirm token using the wrong envelope sender. Stephen proposal that only generated text is sent and only for valid tokens is a good, even if spammers could still make a mailman site blacklisted. But this is verging on the paranoid side. I think these are important (and perhaps related to security) issues. I am only happy that I chose to put our mailman installation on a different network from our domain MTA, just to be sure that it did not get blacklisted. Giuliano _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://www.python.org/cgi-bin/faqw-mm.py Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq01.027.htp
