"changed" field should be deleted
Dear folks, Nowadays I can see a new style of anti-spam fight. 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). :-( So these uneducated lamers multiply the amount of spam and harras a dozen of peoples who are not responsible for the original junk mail and the spam relays. The lamers cannot diffrentiate the "responsible persons" and those who maintain the database records itselves. 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? (Personally I've changed my jobs years ago but my e-mail address can be found in hundreds of *ch fields. So I hate the anti-spam spam as well than the spam itself.) Regards Gabor
I agree that this needs attention. The whole changed: functionality should be reviewed. I agree that a short term measure could be to suppress changed information unless explicitly requested. This would also allow us to check the whois query logs for those requesting it ...;-). Does anyone know if this would break any knows scripts or uses of the database? Daniel
kissg@sztaki.hu writes: Dear folks,
Nowadays I can see a new style of anti-spam fight.
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). :-(
So these uneducated lamers multiply the amount of spam and harras a dozen of peoples who are not responsible for the original junk mail and the spam relays. The lamers cannot diffrentiate the "responsible persons" and those who maintain the database records itselves.
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?
(Personally I've changed my jobs years ago but my e-mail address can be found in hundreds of *ch fields. So I hate the anti-spam spam as well than the spam itself.)
Regards
Gabor
On Fri, Jun 05, 1998 at 03:18:28PM +0200, Daniel Karrenberg wrote:
I agree that this needs attention. The whole changed: functionality should be reviewed.
I agree that a short term measure could be to suppress changed information unless explicitly requested. This would also allow us to check the whois query logs for those requesting it ...;-). Does anyone know if this would break any knows scripts or uses of the database?
Daniel
Hiding the changed: lines definitely breaks every system that keeps _copies_ of the entries because it is impossible to update entries from these copies without trashing the existing entries. And if you make the changed: line availables optionally then those who want to use addresses will quickly figure out how to get them. Greetings, -- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ]
On Fri, 5 Jun 1998, Michael van Elst wrote:
Hiding the changed: lines definitely breaks every system that keeps _copies_ of the entries because it is impossible to update entries from these copies without trashing the existing entries.
And if you make the changed: line availables optionally then those who want to use addresses will quickly figure out how to get them.
Perhaps the displayed/retrieved version of the "changed" field should include a message-id instead of the e-mail address? These are supposed to be unique, and usually contain a hostname/FQDN that is probably sufficient to identify the updater. I am assuming that the vast majority of people make updates using e-mail... Joe -- Joe Abley <jabley@clear.co.nz> Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/
On Sat, 6 Jun 1998, Joe Abley wrote:
Perhaps the displayed/retrieved version of the "changed" field should include a message-id instead of the e-mail address? These are supposed to be unique, and usually contain a hostname/FQDN that is probably sufficient to identify the updater.
I am assuming that the vast majority of people make updates using e-mail...
Actually, thinking about it, why is the changed field "id" an e-mail address at all? Given that most (all?) records are protected to some degree by maintainer fields, surely anything good enough to identify the changer to his fellow maintainers would do? A quick fix might be to expunge all text immediately following the "@" in the changed fields of current records? Or perhaps simply return the records in response to queries with the changed fields munged in a similar way? Joe -- Joe Abley <jabley@clear.co.nz> Tel +64 9 912-4065, Fax +64 9 912-5008 Network Architect, CLEAR Net http://www.clear.net.nz/
On Sat, 6 Jun 1998, Joe Abley wrote:
Actually, thinking about it, why is the changed field "id" an e-mail address at all? Given that most (all?) records are protected to some degree by maintainer fields, surely anything good enough to identify the changer to his fellow maintainers would do?
It can also be useful to the site itself since it documents which of n people actually did the last update.
Joe Abley <jabley@clear.co.nz> writes:
Perhaps the displayed/retrieved version of the "changed" field should include a message-id instead of the e-mail address? These are supposed to be unique, and usually contain a hostname/FQDN that is probably sufficient to identify the updater.
I am assuming that the vast majority of people make updates using e-mail...
Can we limit the discussion to the quick fix of hiding the changed field for standard queries. The re-design of the audit trail has been discussed before and should be considered thoroughly based on a proposal covering all aspects. Daniel
Michael van Elst <mlelstv@xlink.net> writes:
Hiding the changed: lines definitely breaks every system that keeps _copies_ of the entries because it is impossible to update entries from these copies without trashing the existing entries.
I do not understand that one. It is quite possible to send an object more than once the the update process. This will result in a NOOP update as documented in http://www.ripe.net/docs/ripe-157.html#toc27. It does not clobber anything. What am I missing?
And if you make the changed: line availables optionally then those who want to use addresses will quickly figure out how to get them.
Gabor's argument was about users with no clue (or scripts) finding addresses in output returned by whois. This would be prevented. Also we can add the usage of this flag to our heuristics which detect patterns in whois queries. Daniel
Hi,
Hiding the changed: lines definitely breaks every system that keeps _copies_ of the entries because it is impossible to update entries from these copies without trashing the existing entries.
I do not understand that one.
If you don't know the changed: lines you cannot update them correctly. The only possible update is one with newly generated changed lines that trash existing changed lines. Of course you could change semantics and merge delivered changed lines with those hidden in the database (or always use the address from the mail headers which might be a problem for people sending updates by a robot). Then you have to invent a new method to delete changed lines (which is currently possible and sometimes needed to correct bad data). In any case, this change _will_ break scripts.
And if you make the changed: line availables optionally then those who want to use addresses will quickly figure out how to get them.
Gabor's argument was about users with no clue (or scripts) finding addresses in output returned by whois. This would be prevented.
At least they do in my experience users with no clue do not write scripts. Instead they use scripts created by others.
Also we can add the usage of this flag to our heuristics which detect patterns in whois queries.
If you cannot rely on being presented all data you cannot use the data. If your heuristic sometimes presents the changed: lines and sometimes not (otherwise it wouldn't be a heuristic) we better drop the changed: lines (and all included information) altogether. Not that I or our customers would like this. Greetings, -- i.A. Michael van Elst / phone: +49 721 6635 330 Xlink - Network Information Centre \/ fax: +49 721 6635 349 Vincenz-Priessnitz-Str. 3 /\ link http://nic.xlink.net/ D-76131 Karlsruhe, Germany /_______ email: hostmaster@xlink.net [ Xlink Internet Consulting GmbH, Sitz Koeln ] [ Amtsgericht Koeln HRB 3526, Geschaeftsfuehrer: Michael Rotert ]
It is my belief that the only info that should be public is the latest info available, not the historical changes. To the one that called me lamer...As far as being called a lamer, that attitude is not appreciated. Its been my experience that many spammers have built up hierarchies, which are hosts that have sub-domains that are all part of the same spamming organization. For legal reasons, anyone and everyone that is related to an IP Address or related higher domains or IP routes are included in the anti-spam message, that way noone can say later, they didn't know or weren't notified about the law. I'm not going to attempt to try and determine to what extent host providers are involved with a spamming operation. In fact, many hosts have acquired "anti-spam" complaint/ticket type emails as a response program to complaints and are using this just as a "front" and have no intention of responding to eliminate spammers on their networks... Therefore, it makes sense to let as many persons associated with lower level domains that are sourced as spammers in order that they (being in an admin position) can forward the complaints and use them to help identify and isolate spammers. Further, I am not going to assume that any IP information contained in a "spam" is indeed a spam. That is for the relative admins and techies to go through their own logs to determine the true origin of the spam. I do agree that historical changes should be limited to ISP/IAP techs, but the rest of the database must remain open for persons to use that information to locate and identify persons and organizations that are along the IP routes. It's like getting a harassing letter from a PO Box owned by a commercial enterprise and not being allowed to get the name and physical address of the company that rents the box. Here, in the US, the public has a right to get almost all information about persons that are responsible in any private company, for many different reasons. Any ISP/IAP organization that receives a dis-proportionate amount of complaints against a sub-domain or host, should take a look at why that particular host or secondary provider has such a high percentage of spammers on their net. Perhaps, they need to change their poicies on spam to keep their site from being a desirable place to spam from. As far as the charge about the spam complaints being spam themselves, that is a non-argument. The email generated in response to spam is an infintesimal amount compared to the spammers that generate 25,000 emails per hour. If you'd like to reply with intelligent subject matter, and knock off the name calling crap, I'd welcome a sincere discussion of these subjects. For an example, you may wish to re-visit how rs.internic.net handles their database information. Very concise, and generally only contains the most recent information that is pertinent to the proper identification of current admin, billing, tech contacts, and IP Addressing/Server Information. Change stuff as history is not included. I'd love to see the extraneous material removed from your ripe.net lookup databases... then perhaps only those persons that really need to know would be contacted.
I agree that this needs attention. The whole changed: functionality should be reviewed.
I agree that a short term measure could be to suppress changed information unless explicitly requested. This would also allow us to check the whois query logs for those requesting it ...;-). Does anyone know if this would break any knows scripts or uses of the database?
Daniel
kissg@sztaki.hu writes: Dear folks,
Nowadays I can see a new style of anti-spam fight.
So these uneducated lamers multiply the amount of spam and harras > a dozen of peoples who are not responsible for the original junk mail > and the spam relays. > The lamers cannot diffrentiate the "responsible
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). :-( persons" and those > who maintain the database records itselves. > > > 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? > > (Personally I've changed my jobs years ago but my e-mail address > can be found in hundreds of *ch fields. So I hate the > anti-spam spam as well than the spam itself.) > > > Regards > > Gabor >
s/James Leonard BRG Customer Service - Belltown Research Group, Seattle, WA USA http://www.speakeasy.org/~belltown SPAM=NET TRAFFIC OVERLOAD=TELECOM $URCHARGE$=GOVT. TAXE$
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. ---
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 think we look at this field in a very different way. For all I care it could be my own internal person-id and date that is indecipherable to anyone else. It doesn't matter to me about UTC either because my own time zone doesn't change... perhaps this would matter to an international backbone provider with NOC's in multiple time zones... so I guess I can see that point, but only if you happen to be such an entity. Why even define it to be an email address? Why not just make it change: company-internal-id company-internal-date-fmt
Dale, On Sat, Jun 06, 1998 at 02:16:00AM +0100, Dale Amon as Operator wrote:
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 think we look at this field in a very different way.
I can agree on this one ;-).
For all I care it could be my own internal person-id and date that is indecipherable to anyone else. It doesn't matter to me about UTC either because my own time zone doesn't change...
But people that are querying your data are coming from different time zones, whether you like it or not. My database 'person:' object is stored in the RIPE database from the times when I was still working at the RIPE NCC. Now, I have a 9 hour time difference. The working area of the RIPE NCC is quite big and it does go over many time zone boundaries. Replies regarding the 'changed:' attribute discussion came from people at the US east coast, west coast, new zealand and europe ...
perhaps this would matter to an international backbone provider with NOC's in multiple time zones... so I guess I can see that point, but only if you happen to be such an entity.
This is a problem for everybody that is located quite some hours from the database. You don't need to be a backbone provider for that.
Why even define it to be an email address? Why not just make it
change: company-internal-id company-internal-date-fmt
There is no need to have a 'changed:' attribute if you want to have some private data stored. The 'remarks:' attribute let's you add the private extensions that you want and in a format that you like (as you can see in many 'remarks:' attribute lines). The RIPE database is intended to store useful public information. Furthermore, this information should be as constitent as possible to make it most useful for it's users. The 'changed:' attribute doesn't really help in this effort due to it's fuzzy definition. David K. ---
On Sat, 6 Jun 1998, David Kessens wrote:
But people that are querying your data are coming from different time zones, whether you like it or not. My database 'person:' object is stored in the RIPE database from the times when I was still working at the RIPE NCC. Now, I have a 9 hour time difference. The working area of the RIPE NCC is quite big and it does go over many time zone boundaries. Replies regarding the 'changed:' attribute discussion came from people at the US east coast, west coast, new zealand and europe ...
I guess I was questioning whether there is a reason for someone else to have this information. I guess there are reasons why someone trackingdown a routing problem might be interested in when something changed. But if that is the case, then why is the time signature generated at source? I should send a changed: line with an id-code of some sort, which could be company internal; the database should generate a UTC time sig at the instant of the update. Otherwise the date sig is pretty pointless. I can personally remember working out a large database change in a file over a couple days before sending it. So that dates were when I generated the data, not when I updated the database. Well, I may have fixed them, but you get the point.
In message <19980605091235Z1152066-5772+279@lutra.sztaki.hu>, kissg@sztaki.hu w rites:
Dear folks,
Nowadays I can see a new style of anti-spam fight.
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). :-(
So these uneducated lamers multiply the amount of spam and harras a dozen of peoples who are not responsible for the original junk mail and the spam relays. The lamers cannot diffrentiate the "responsible persons" and those who maintain the database records itselves.
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?
(Personally I've changed my jobs years ago but my e-mail address can be found in hundreds of *ch fields. So I hate the anti-spam spam as well than the spam itself.)
Regards
Gabor
There is a general problem with publicly available email contact information. I would prefer to solve the general problem. One way to solve the general problem is if by convention, contact information provided in the database is only provided for organizations (effectively role objects) or for mail aliases for individuals that are specifically for operational correspondence. I'd like the convention to also require that any correspondence to these mail aliases would be PGP signed (or otherwise crytographically signed, if S/MIME or something else becomes prevalent). If it wasn't signed by a recognized key, then the mail would be tossed out. This would completely eliminate SPAM to operational contact mail aliases. I'd also like to see the keys limited to those in the RR when that becomes a reality. Such an alias might be separate from customer contact mail aliases so that customers could still send non-signed mail. This is clearly just a suggestion at this point and even if adopted is not a short term solution. Curtis
participants (8)
-
.J Leonard -
Curtis Villamizar -
Dale Amon as Operator -
Daniel Karrenberg -
David Kessens -
Joe Abley -
kissg＠sztaki.hu -
Michael van Elst