Gunnar, On Wed, Sep 09, 1998 at 08:55:56PM +0200, Gunnar Lindberg wrote:
Folks, I'm not on this list but <ripe-dbm@ripe.net> suggested I send the idea to you. Right now I hope there is no spam-filter :-).
My suggestion:
Could you please make <auto-dbm@ripe.net> keep the Cc: list and return responses to everybody on it (as well as everybody on To:).
Motivation:
Sending a request with a Cc: is usually because you want other people to be aware of what happens. Since <auto-dbm@ripe.net> doesn't keep Cc: that doesn't work and you have to forward the response manually. Now, of course *I* NEVER forget such a thing, but others do... :-).
The suggestion and motivation is excellent, but there are nasty side effects in practice: Including the Cc: field is a nice way to create mailloops. Currently, The 'From:' field (note: not the 'To:' field) is used which is a field that is set by the user upon arrival of the update message and set by the db after sending the message as the human mail box of the database. If a user accidently sets it's 'From:' field with a value that points to an autoresponder, the db will send a message to the autoresponder and will get automatically a message sent back. However, this message is sent to the human mail box and thus no mailloop is created. When the 'Cc:' address would be used too, there is no way for the database to break the loop since the 'Cc:' address is set by the user and can possibly contain the automatic mail address of the db and/or a (local) alias to the db. Since, parsing of mail addresses is a bit ambiguous to say the least and people can use their own local aliases (which are not known to the database), it is extremely hard to filter the automatic mail address out of the 'Cc:' list and thus mailloops can easily occur. With the volume of mail that RIPE receives, broken mail systems and user errors like this do happen and would result in an unstable db system which is not very desirable. Of course, one can build, with a lot of (artificial) intelligence, nice work arounds that catch 99% of the problems but I would prefer to keep things simple to keep them working robust, fast and efficiently. David K. ---