This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[anti-abuse-wg] Manual vs automated reports
- Previous message (by thread): [anti-abuse-wg] Manual vs automated reports
- Next message (by thread): [anti-abuse-wg] Manual vs automated reports
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
peter h
peter at hk.ipsec.se
Tue Jul 24 19:59:29 CEST 2012
On Tuesday 24 July 2012 17.34, Luis Muñoz wrote: > Hi there, > > I've been quickly going through the archives to try to catch up in the discussion after reading the current document. It struck me as odd that the role objects will have a single abuse-mailbox object which should be used to receive both automatic and manual reports. I'm aware of this (related) exchange (from the archives): > > >From Tobias Knecht > > > Is it for high volume automated report dissemination (trap or sensor initiated > > > identification of "activity")? > > > > > For this to work it needs automated handling on the receiving side and it should > > > be clearly opt-in, so that the receiving entity can prepare for proper processing. > > > > Disagree from my experience in the anti-abuse industry. First of all > > reporting must be easy and receiving reports must be easy as well. [...] > > > > Second, if you do not want to receive reports from one party, block them > > or directly delete them. That is best practice and widely adopted and > > really not complicated to do. [...] > > > While this matches my experience -- and I'm sure this will also match with the experience of anybody who has > had to handle a large volume anti-abuse operation -- I remember there were times where I wished there was an > easier way. > > The automated reports tend to vastly outnumber the manual reports, which also mix with the loads of spam > that are (purposely?) pointed at the abuse contacts. This complicates the task of sifting through the mail > flow to direct the complaints into their proper bins for processing. There's also the case of those that > don't care about abuse originating from their resources. Those are likely to simply devnull their abuse c > omplaint flow just as they have been doing up until now. > > I believe that having an optional "auto-abuse-mailbox" object (that is mandatory to use when present) > dealing only with automated reports, could help anti-abuse operators (both in the report sending and > receiving sides). The automated, high volume generators can decide not to waste resources with entities > that do not have the right objects setup (ie, if there's not an auto-abuse-mailbox, do not generate the > report) and the entities that are not prepared to deal with automated reports, could signal that to the > community by not defining an auto-abuse-mailbox. This would send the wrong signal to the community ( that we only deal with the easy cases and with less and less resources) Spam has been the plague that it is since ISP's have ignored abuse reports about their customers. The way to reduce work with abuse reports is NOT to ignore some of them ( or make life easier for the abuse staff) but to reduce the amount of abuse originating from it's own adresses. Blacklisting is the only thing that really bites ignorant ISP's, and that's what happens. > > Note that I still support the notion of a mandatory abuse-mailbox where manual complaints can be sent. At > least that takes a way a lot of (guess)work out of figuring out where to send the complaint. > > Best regards > > -lem > > > > > > -- Peter Håkanson There's never money to do it right, but always money to do it again ... and again ... and again ... and again. ( Det är billigare att göra rätt. Det är dyrt att laga fel. )
- Previous message (by thread): [anti-abuse-wg] Manual vs automated reports
- Next message (by thread): [anti-abuse-wg] Manual vs automated reports
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]