[db-wg] Action item 47.2: Proposal for Adding Abuse Contact

On Thu, 2004-04-08 at 10:52, Gert Doering wrote:

> On Thu, Apr 08, 2004 at 10:07:54AM +0200, Jeroen Massar wrote:
> > Did you request an IRT object for your organisation and implement it?
> > It only took me a couple of hours as I mentioned some time ago.
> 
> If you have a PGP infrastructure in place (or you have only *one* person
> reading PGP-encrypted abuse e-mails) it's easy.
> 
> We haven't setup an IRT object for us yet, because there is no key 
> we can put into the "encryption:" field without breaking internal
> processes.  Abuse handling does *sign* outgoing mails, but those are 
> personal keys, not group keys.

Nothing requires communications to be PGP encrypted (afaik).
Signing email is something that most people should do anyways
even it is just to protect yourself from fakers/emails etc
and making it a way to prove that you where the one writing
the email and not someone/thing else.

Most endusers, which seems to be the target here, won't have a pgp
capable email system in place. Automated tools won't do pgp signing
nor encryption either as then they would need to fetch + trust the
key automatically and I think that is not an option in most cases.

> As abuse at space.net runs through a ticketing system that doesn't know
> PGP (yet, the next generation will), having a mandatory encryption: 
> field here is a major obstacle - and putting personal mailboxes and
> keys into the irt: object is not overly useful.
>
> We'd be quite happy to implement a "lightweight abuse-contact reference"
> solution.

I assume that quite a lot of parties would indeed be happy when
at least the encryption field would be optional.

On Thu, 2004-04-08 at 11:28, MarcoH wrote:
> Did you request an IRT object for your organisation and implement it?
> > It only took me a couple of hours as I mentioned some time ago.
> 
> That's not the problem. The problem is that the IRT-object will
> only carry the more generic e-mail attribute. From the operational
> experience I have, it looks like a lot of 'users' have trouble to
> distinguish all the e-mail atrributes and mail addresses in the
> whois output and find the correct one.

Thus adding 'more specific' email addresses into the irt object
might be a solution to this problem?

You can already do that, with the same way you, or was it someone else,
proposed the abuse-mailbox format:

...
email: spam at example.com # SPAM
email: ddos at example.com # DDOS
...

The IRT object also has remarks and comment fields so one can fill
it with large ASCII drawings and other ways to make it clear to the
user. The advantages for the ISP:
 - only one top-level object to add
 - only one object to manage/change
 - central in place
 - works now and already for quite some time.

> The abuse-mailbox: attribute should be clear to everybody and makes
> automation much easier for the generic user, who never read
> the database specs, but only looks at the raw whois output.

If a 'user' automates, they are no endusers any more but toolwriters.
When a toolwriter doesn't read the specs they should be hit by a
cluestick :) There is nothing/not much you can do against ignorant
(end)users.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 240 bytes
Desc: This is a digitally signed message part
URL: </ripe/mail/archives/db-wg/attachments/20040408/62feffb9/attachment.sig>