--On 19 October 2006 10:35:37 +0900 stephen@xemacs.org wrote:
Giuliano Gavazzi writes:
I have then noticed that the confirm address (listname-confirm +...@...) and the request address (listname-request@...) 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 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.
-- Ian Eiloart IT Services, University of Sussex