On Thu, Apr 08, 2004 at 12:05:33PM +0200, Jeroen Massar wrote:
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:
Yes, but don't call it e-mail. You want something you can easily filter on, because apparently, looking at the number of wrongly addressed complaints and the addresses they use, a lot of people tend to grep on the '@' sign. There are 2 problems in the real world, 10 % of the inet(6)num objects use the freeform 'remarks' attribute for pointers to the abuse department, which makes automation harder and the e-mail attribute is highly overloaded, you need to look at the context to find out if it's the correct one (returned in an IRT object). I'm not opposed to the IRT object, but is not very helpful for the millions of people out there who only want to send a simple spam complaint and trust on some piece of script they downloaded somewhere. So what's the chance people will actually introduce enough IRT objects to make it usefull to look for them and at the same time enough toolwriters with some decent knowledge about the database to find the correct e-mail attribute ? So the real question is, what will change if we introduce a specific attribute which people can actually find using 'grep' on the full output. Which we can use to replace all the remarks attributes. Oh and while we are advertising it, we might as well put in some pointers on irt. MarcoH