[Mailman-Developers] list confirm and request addresses acting as open relay

[Giuliano Gavazzi]

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  
>> 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