Gabor, On Fri, Jun 05, 1998 at 11:12:32AM +0200, kissg@sztaki.hu wrote:
If the victim gets some junk mail, (s)he retrieves all database objects (including *rt) relative to ALL hosts, domains, and IP addresses that can be found in the mail header, and s(he) send complaining mails to ALL the fifty e-mail addresses found in the database objects (including the *ch field). :-(
Why don't you use fake e-mail addresses in the 'changed:' field if you are concerned about this ... I recently posted some messages regarding the 'changed:' field at the <rps@ISI.EDU>. Below follows a summary. The whole changed field is a bad idea in general. It's use is not clear and it's contents are not reliable. We will first need to define where the 'changed:' field is actually for: - recording the history of changes: - timestamp when changes were made - identify who made the changes and how to retrieve the update message - identify which previous object was changed Al these uses are not very well served by the 'changed:' field right now. People can change them at will (fun to confuse people), the timestamp is not UTC (very annoying for people living in other timezones) and it doesn't provide the time of changes (interesting if you make more then one change a day). I would propose to get rid of the 'changed:' field altogether, but first define a more sound replacement with the following requirements: - the new field should be added by the database itself - the new field have a full UTC timestamp - the new field should uniquely identify an object (serial number) - the new field should identify which object it replaces - the new field should record which maintainer was resposible for the changes if a maintainer was involved. Actually, it probably makes sense to allow updates by maintainers only, even for objects that are not protected by maintainers. - it makes sense to have some form of identification of the update message to facilitate lookups in case of problems. An mail message id or any other id that the db possibly generates itself could help. These features don't necessarily should be folded into one attribute, and they might also not be viewed upon query by default. This would also solve another problem with the db: You will be able to delete messages by doing something like: password: MyPasswd delete: MNT-DAVID ObjectID instead of the problematic 'duplicate the full object deletion process'. Note that software support for such a field is not difficult what so ever. Most of the building blocks are present in the software. The specification is the most difficult part.
My first radical suggestion is: Let's delete the *ch field from the database objects.
However I know that there should be some info about the history of records.
a few raw ideas: - modified database software that hides the *ch field. *ch's could be retrieved with some extra efforts only - some coded ID instead of e-mail address. Ordinary peoples couldn't decode it but authorized ripe-ops could. (E.g. via WWW or e-mail) This info shouldn't be public.
What is your opinion?
I don't think it helps much to spend a lot of effort in trying to fix an inherently broken attribute. We better spend our time to replace it with something new that really addresses the problem. We will else end up adding all kind of hacks every few months to work around the unsolved problem. David K. ---