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