Re: Cc: in <auto-dbm> replies

[David Kessens <]

Gunnar,

On Wed, Sep 09, 1998 at 08:55:56PM +0200, Gunnar Lindberg wrote:
>
> Folks, I'm not on this list but ripe-dbm@localhost suggested I send
> the idea to you. Right now I hope there is no spam-filter :-).
>  
> My suggestion:
> 
>     Could you please make auto-dbm@localhost 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@localhost
>     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.
---