[anti-abuse-wg] the mandatory abuse field

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.

You were 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.

Hm, this is estimation.

There are people that are not publishing contacts, because
- they dont know that they can or should, simply because
   nobody told them or that their RIPE member decided
   not to publish some
- some have typing mistakes
- some have deliberatly wrong format, hoping that only
   humans report (like @ti.ru.only or some adding a
   .remove.this.suffix at the end)

You cannot say whats really happening.
It could be that the amount of right and working contacts
is increasing. Or you could be right.

You cannot compare both situations (the current and the coming)
right now, I would say, its getting easier for the reporter, because
then you can send a report and analyse any bounces.
You will see, if the resource owner wants a report,
after your report bounces.

Currently there are a lot of networks, that probably want
a report, but you will send it to the wrong address,
simply because you cannot make a decision, wich
contact or remarks or IRT object you should use.
A lot of reports are being send to a contact, that
was not intended by the resource owner and will
be ignored or unread because of the current situation.

>>
>> 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.

Like sayd before, the abuse-c will lead to an semi-automatic clean-up, 
because the resource owners have to re-think his situation.
Surely they will remove a lot of old remarks and IRT objects used
only for this purpose, simply because its right.

> In general, I support cleaning up existing mess before making new mess. Maybe I'm just a "neat freak", though.

Neat is nice ;o)

>> 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.

See above.
The reporter can then 100% sure, that he picked the right address, and
if it bounces, well, looks like to resource holder does not want
reports ... makes things much easier for the reporter.

> I do not think "but you have to do this anyway" is a good reason for making the problem bigger.

If there is something non-mandatory, you cannot decide if the resource
owner deliberatly decided not to publish one, or if he simply
forgot to add one (because he is not forced too).
There is lots of field, that could be added, but nobody does
it, because its less work (even if its useful for himself).
I guess, that there are lots of old objects, that were not
updated, when the abuse-mailbox field was introduced.

Having it non-mandatory will lead to more confusion, because the 
resource owners thinks, that everything is in its place and keeps
the old methods.

So, having it non-mandatory will make the problem bigger like you sayd.

Having it mandatory will result in a semi-automated cleanup and a
real decision by the resource owner, like the NCC outlined in the
proposal.


An option could be the following:
the possibility to set the abuse-mailbox field to something like
"non-responsive", a predefined value, thats valid according
to the format of the field. The cleanup will happen, the resource owner
makes a decision and the reporter could see, that the
resource owner does not want to have reports (via email) ...


Kind regards, Frank

>
> Regards,
>
> Leo Vegoda
>



-- 

Mit freundlichen Gruessen,
--
MOTD: "have you enabled SSL on a website or mailbox today ?"
--
PHADE Software - PowerWeb                       http://www.powerweb.de
Inh. Dipl.-Inform. Frank Gadegast             mailto:frank at powerweb.de
Schinkelstrasse 17                                fon: +49 33200 52920
14558 Nuthetal OT Rehbruecke, Germany             fax: +49 33200 52921
======================================================================