list confirm and request addresses acting as open relay
Hello, sorry if this is a dumb observation, but recent spam to the
posting address of on of our lists (fortunately a moderated
distribution-only list) has prompted some test on my part.
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.
Until now no spammers have used this, but sooner or later they will.
For the "confirm" case I suppose a solution would be to only reply to
confirm strings that are in the database and only if the envelope
sender IS the one associated to the particular confirm string.
For the "request" case instead the situation is more complex. The
reply should only be generated if the sender is a subscriber to the
list, unless, of course, the subject is "subscribe". If it is a
subscribe though the body of the message does not contain the
original body and the damage is limited. In this "subscribe" case
perhaps a throttling or maximum number or outstanding subscription
requests would be a good idea.
Of course this might be in the latest release but I did not find
mention in the list.
Thank you
Giuliano
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.
--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
On 19 Oct 2006, at 11:47, Ian Eiloart wrote:
--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 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
Giuliano Gavazzi wrote:
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.
Or more simply, just remove the relevant alias entries in the mail server configuration.
-Dale
participants (4)
-
Dale Newfield -
Giuliano Gavazzi -
Ian Eiloart -
stephen＠xemacs.org