Leo Vegoda wrote:
Hi Frank,
On Jul 31, 2012, at 7:03 am, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
Leo Vegoda wrote:
Hi Frank,
On Jul 28, 2012, at 12:19 pm, Frank Gadegast <ripe-anti-spam-wg@powerweb.de> wrote:
or no-reply@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@powerweb.de Schinkelstrasse 17 fon: +49 33200 52920 14558 Nuthetal OT Rehbruecke, Germany fax: +49 33200 52921 ======================================================================