Re: "changed" field should be deleted

[Curtis Villamizar <]

In message <19980605091235Z1152066-5772+279@localhost>, kissg@localhost 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