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@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@example.com # SPAM email: ddos@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