[Mailman-Developers] list confirm and request addresses acting as open relay
dev+lists at humph.com
Thu Oct 19 13:10:01 CEST 2006
On 19 Oct 2006, at 11:47, Ian Eiloart wrote:
> --On 19 October 2006 10:35:37 +0900 stephen at xemacs.org wrote:
>> Giuliano Gavazzi writes:
>> > I have then noticed that the confirm address (listname-confirm
>> > +... at ...) and the request address (listname-request at ...) act as
>> > mirrors to the alleged envelope sender, sending back the whole
>> > after the parsed commands.
>> This kind of thing has been mentioned, I think, in respect of bounce
>> 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
>> 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.
More information about the Mailman-Developers