[anti-abuse-wg] the mandatory abuse field

Dear Leo

As I follow these discussion my mind keeps focussing on the Abuse Finder 
tool and the technical nightmare we have right now in trying to make 
that work. One of the many problems with it is we cannot parse remarks 
that (may) include abuse contacts.

Even with the "abuse-c:" proposal we still cannot 'prevent' (by any 
technical means) users from putting an abuse contact in a remark 
anywhere in their data set that seems a logical place to them.

Using a double negative approach (if you don't want to handle abuse, 
don't add an abuse contact) presents the same technical problem for the 
Abuse Finder tool. Not all users of the RIPE Database read the 
documentation and follow discussions on the mailing lists. If there is 
no requirement to put an "abuse-c:" in a specific place, some of these 
users will still add it in a remark somewhere. Technically we can't 
prevent them and also will not know about it if they do.

So if the community chooses to make it optional (and the RIPE NCC will 
implement it in whatever way the community chooses), you need to accept 
that the Abuse Finder tool cannot then take the absence of an "abuse-c:" 
to mean there is no abuse contact. We are still in the same state we are 
in now. All the Abuse Finder tool can say is, we can't find an abuse 
contact, but we saw some reference to the word 'abuse' in "remarks:" or 
"e-mail:" attributes in these objects, go take a look yourself because 
we are not sure.

Regards
Denis Walker
Business Analyst
RIPE NCC Database Group


On 31/07/2012 16:28, Leo Vegoda wrote:
> Hi Frank,
>
> On Jul 31, 2012, at 7:03 am, Frank Gadegast <ripe-anti-spam-wg at powerweb.de> wrote:
>> Leo Vegoda wrote:
>>> Hi Frank,
>>>
>>> On Jul 28, 2012, at 12:19 pm, Frank Gadegast <ripe-anti-spam-wg at powerweb.de> wrote:
>>>
>>
>>>> or
>>>> no-reply at example.com
>>>> or send it to devnull …
>>>
>>> I think you are arguing in favour of forcing people to tell a small lie about abuse reporting addresses to improve the completeness of the database. Database users then need to parse all e-mail addresses and work out which patterns should be ignored. I do not understand why you want reporters to be forced to do additional processing to reach a decision about whether it is worth attempting to send an abuse report. Can you please explain the benefit to abuse reporters?
>>
>> Simply because its better to have ONE place for reporters.
>
> I don't think I have been clear. Sorry. What I meant was that if someone does not want reports and you force them to tell a lie about where to send reports then you increase the burden on the reporter, who has to parse the e-mail address and try to guess if it is a fake address or not. If, instead, people who do not want to receive reports do not have to publish an address then allowing them to not publish an address allows the reporter to reach the same conclusion more quickly.
>
>> Forcing these addresses to be working and correct is
>> not part of this proposal and could be discussed later
>> (and fixed with another proposal).
>>
>> Currently there are lots of places to store the abuse-contact
>> and a lot of them are wrong, because of a lie, lacyness,
>> technical problems or whatsoever.
>
> I think that standardising the place to publish an address and a cleanup process for old data are distinct and separate problems. I agree that the current mishmash of methods used makes life difficult for reporters but making people add new data before a policy or mechanism for cleaning old data has even been formally considered is just going to make the problem bigger. In general, I support cleaning up existing mess before making new mess. Maybe I'm just a "neat freak", though.
>
>> In future you will have only one place to look for it,
>> probably also with a lot of wrong addresses.
>>
>> Anyway, it would be better than it is now.
>>
>>>> Lots of resource holders are already doing the same,
>>>> we keep a list of there email addresses, so
>>>> we do not have to send them reports that
>>>> will only fill our mail queue to bounce back.
>>>> I can understand them and respect that others
>>>> like to work things different and we do not
>>>> send them reports anymore.
>>>
>>> I do not want to encourage the development of more business logic like this.
>>
>> You do need this logic already (even if that logic consist only
>> of an reply-address for your abuse reports, that you do not read at all ;o)
>> You already have this logic, if you have a ticket system for the reports
>> you send out. You then have to deal with all these bounces since you
>> started reporting …
>
> By forcing people to tell a lie about where to send reports you just exacerbate the problem. I do not think "but you have to do this anyway" is a good reason for making the problem bigger.
>
> Regards,
>
> Leo Vegoda
>