DRAFT: RIPE proposal - implementation of an abuse monitor system
Dear all, please discuss and comment to following draft proposal ... (and please forgive but correct my english, bad formatting or terms) Kind regards, Frank -------------------------------------------------------------- DRAFT: implementation of an abuse monitor system (draft RIPE proposal) Abstract This document describes the implementation of an abuse monitor system at RIPE NCC. Its intention is to ensure working abuse contacts on the members side and to improve the awareness, responsiveness and work flow for abuse reports for the reporting (and abused) internet users and the RIPE members (owning the misused services). Contents 1. Introduction 2. Goals of an abuse monitor system 3. Requirements 4. Description 5. Advantages 6. Disadvantages 7. Enhancements 8. Outlook 1. Introduction Taking in account the amount of spam and other abuse currently happening every day, there is a need to ensure that ISPs and other organisations are aware of the problem their customers and end users can cause for others. The current procedure of having non-mandatory abuse contacts in whois output is causing several problems for the incident reporting side as well as for the receiver. RIPEs member should be responsible for the abuse their customers cause, like this is enforced by law in many countries already. 2. Goals of an abuse monitor system Currently most abuse contact addresses are hidden in whois output remark fields in several non-standarized ways or do not even exist, because the real abuse-field is non-mandatory. There should be a standarized method how to contact responsible people to send abuse reports too. It should be possible to to send abuse reports to a standarized email address, because whois queries are limited. The system should bypass whois queries, so that reports can be automated. Currently there is no control, if existing abuse contacts are still valid, working or incoming emails are beeing read. The real abuse email address of any RIPE member should be hidden by the abuse monitor system. Finally a monitoring system should be able to messure the amount of incoming reports for any RIPE member. This will enable RIPE NCC to help members to become more aware of security breakouts or help members that are not aware of the problems they cause. RIPE NCC could e.g. arrange for security training cources and invite members with a very high reporting rate according to the amount of allocated IP addresses. 3. Requirements RIPE NCC should enhance the member section with an extra abuse contact field. This field should be filled at startup with the main email address of any member automatically, but should be editable for the members. 4. Description RIPE NCC should implement a mailserver able to receive emails in the form of IP1.IP2.IP3.IP4@abuse.ripe.net (example) Incoming emails to these addresses can be treated as incoming abuse reports and will be forwarded to the members internal abuse contact address (non-public), after the mailserver finds the correct member by looking up internal allocation tables. The amount of incoming emails for every member will be logged and should create internal statistics for RIPE NCCs internal usage. Their should be no anti spam systems implemented on this server to ensure that every incoming email gets forwarded. Anti spam systems should be up to the member. Furthermore, RIPE NCC should monitor, if the members abuse contact address generates errors, bounces or other problems like "User unknown" or "Mailbox full". If the members abuse contact address is not valid anymore, it could be reset to the members hidden main email address, and the member could be informed about the problem in other ways (letter, phone call aso). 5. Advantages The system does neither have to define or decide what spam or abuse is, because it only forwards abuse reports to the responsible person. It is likely that any incoming email is a description of a real abusive problem (except incoming spam). The described system would make it very easy for any ISP or private person to report received spam, hacks or other abuses directly to the responsible RIPE member, without having to know its name and without having to know how to use whois. Reporting systems could be easily automated without having to query whois. The ISP or RIPE member can easily change and control his internal abuse contact address without having to update several objects in RIPEs database. RIPE NCC can ensure that all alocations have a working abuse address. This all can ensure that incidents are really reported by the abused users (and not beeing ignored or forgotten because its to much work to report incidents) and that reports will be read by the right and responsible person. This will finally increase the awareness of any RIPE member about the problems his end users or misused servers may cause and will hopefully force any member to implement methods to monitor there own servers and/or dialin users to improve the detection of misused services. This will hopefully reduce the amount of spams and abuse worldwide. Finally this will maybe influence other RIRs to implement similar systems. 6. Disadvantages It is likely that spammer will misuse the new general abuse adresses massively. Anti spam methos needs to be implemented at the members side. 7. Enhancements The system could be enhanced with addtional services easily on RIPE NCCs side, after implementation and a test period of the system. More detailed statistics could help improving the awareness at the members side. Enhancing forwarded abuse report with an feedback link could help to categorize incoming reports. Members could then visit a ticket system to back report incoming reports as "spam", "incident" or "wrong report" (like popular spam blacklist like SpamCop are doing this already), add comments like "missing information", "incident currently under investigation" or "incident solved". This could help members to track reports and incident easily without having to implement a own system (what could be very interesting for smaller ISPs). Finally this would allow the reporting internet user to receive feedback to ensure that his input is valuable, important and taking care off. 8. Outlook Standarization of a general abuse address will be another step to the standarization of an abuse report format, wich are currently in process. This could lead to open source implemantations of spam detection solutions that include standarized reporting features. Standarized reporting could also be included in other monitoring and detection software, like Intrusion Detection Systems or Antispam Solutions. Author: Frank Gadegast Company: PHADE Software - PowerWeb Contact: frank@powerweb.de Version: 0.1 Date: 08.04.2010
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maybe I am missing something but I can't see the benefit in having RIPE proxy abuse requests, as a member of a CSIRT I feel this would add a layer of abstraction between the 2 network operators and definitely wouldn't use it as a first port of call. Additionally RIPE are not in a position to force the badly behaving ISPs to cooperate, if you have an uncooperative ISP with problem X do you really believe that RIPE suggesting they go on a training course is going to help? Sure the RIPE NCC may have some other contact details but most ISPs within the RIPE region you can get hold of even if the abuse mailbox does not work by making a few phone calls etc. And if the only benefit is a common abuse alias, hasn't this has already been suggested with an abuse@ address in RFC2142 - Mailbox Names for Common Services, Roles and Functions which is not RIPE region specific? Bradley
-----Original Message----- From: anti-abuse-wg-admin@ripe.net [mailto:anti-abuse-wg- admin@ripe.net] On Behalf Of Frank Gadegast Sent: 08 April 2010 14:30 To: anti-abuse-wg@ripe.net Subject: [anti-abuse-wg] DRAFT: RIPE proposal - implementation of an abuse monitor system
Dear all,
please discuss and comment to following draft proposal ... (and please forgive but correct my english, bad formatting or terms)
Kind regards, Frank
--------------------------------------------------------------
DRAFT: implementation of an abuse monitor system (draft RIPE proposal)
Abstract This document describes the implementation of an abuse monitor system at RIPE NCC. Its intention is to ensure working abuse contacts on the members side and to improve the awareness, responsiveness and work flow for abuse reports for the reporting (and abused) internet users and the RIPE members (owning the misused services).
Contents 1. Introduction 2. Goals of an abuse monitor system 3. Requirements 4. Description 5. Advantages 6. Disadvantages 7. Enhancements 8. Outlook
1. Introduction Taking in account the amount of spam and other abuse currently happening every day, there is a need to ensure that ISPs and other organisations are aware of the problem their customers and end users can cause for others.
The current procedure of having non-mandatory abuse contacts in whois output is causing several problems for the incident reporting side as well as for the receiver.
RIPEs member should be responsible for the abuse their customers cause, like this is enforced by law in many countries already.
2. Goals of an abuse monitor system Currently most abuse contact addresses are hidden in whois output remark fields in several non-standarized ways or do not even exist, because the real abuse-field is non-mandatory. There should be a standarized method how to contact responsible people to send abuse reports too.
It should be possible to to send abuse reports to a standarized email address, because whois queries are limited. The system should bypass whois queries, so that reports can be automated.
Currently there is no control, if existing abuse contacts are still valid, working or incoming emails are beeing read.
The real abuse email address of any RIPE member should be hidden by the abuse monitor system.
Finally a monitoring system should be able to messure the amount of incoming reports for any RIPE member. This will enable RIPE NCC to help members to become more aware of security breakouts or help members that are not aware of the problems they cause.
RIPE NCC could e.g. arrange for security training cources and invite members with a very high reporting rate according to the amount of allocated IP addresses.
3. Requirements RIPE NCC should enhance the member section with an extra abuse contact field. This field should be filled at startup with the main email address of any member automatically, but should be editable for the members.
4. Description RIPE NCC should implement a mailserver able to receive emails in the form of
IP1.IP2.IP3.IP4@abuse.ripe.net (example)
Incoming emails to these addresses can be treated as incoming abuse reports and will be forwarded to the members internal abuse contact address (non-public), after the mailserver finds the correct member by looking up internal allocation tables.
The amount of incoming emails for every member will be logged and should create internal statistics for RIPE NCCs internal usage.
Their should be no anti spam systems implemented on this server to ensure that every incoming email gets forwarded. Anti spam systems should be up to the member.
Furthermore, RIPE NCC should monitor, if the members abuse contact address generates errors, bounces or other problems like "User unknown" or "Mailbox full". If the members abuse contact address is not valid anymore, it could be reset to the members hidden main email address, and the member could be informed about the problem in other ways (letter, phone call aso).
5. Advantages The system does neither have to define or decide what spam or abuse is, because it only forwards abuse reports to the responsible person. It is likely that any incoming email is a description of a real abusive problem (except incoming spam).
The described system would make it very easy for any ISP or private person to report received spam, hacks or other abuses directly to the responsible RIPE member, without having to know its name and without having to know how to use whois. Reporting systems could be easily automated without having to query whois.
The ISP or RIPE member can easily change and control his internal abuse contact address without having to update several objects in RIPEs database.
RIPE NCC can ensure that all alocations have a working abuse address.
This all can ensure that incidents are really reported by the abused users (and not beeing ignored or forgotten because its to much work to report incidents) and that reports will be read by the right and responsible person.
This will finally increase the awareness of any RIPE member about the problems his end users or misused servers may cause and will hopefully force any member to implement methods to monitor there own servers and/or dialin users to improve the detection of misused services.
This will hopefully reduce the amount of spams and abuse worldwide.
Finally this will maybe influence other RIRs to implement similar systems.
6. Disadvantages It is likely that spammer will misuse the new general abuse adresses massively. Anti spam methos needs to be implemented at the members side.
7. Enhancements The system could be enhanced with addtional services easily on RIPE NCCs side, after implementation and a test period of the system. More detailed statistics could help improving the awareness at the members side.
Enhancing forwarded abuse report with an feedback link could help to categorize incoming reports. Members could then visit a ticket system to back report incoming reports as "spam", "incident" or "wrong report" (like popular spam blacklist like SpamCop are doing this already), add comments like "missing information", "incident currently under investigation" or "incident solved". This could help members to track reports and incident easily without having to implement a own system (what could be very interesting for smaller ISPs). Finally this would allow the reporting internet user to receive feedback to ensure that his input is valuable, important and taking care off.
8. Outlook Standarization of a general abuse address will be another step to the standarization of an abuse report format, wich are currently in process. This could lead to open source implemantations of spam detection solutions that include standarized reporting features. Standarized reporting could also be included in other monitoring and detection software, like Intrusion Detection Systems or Antispam Solutions.
Author: Frank Gadegast Company: PHADE Software - PowerWeb Contact: frank@powerweb.de Version: 0.1 Date: 08.04.2010
-----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.0.0 Charset: us-ascii wsBVAwUBS73dxjR8IIjdC+5SAQJEAQf/cG+OZ3r0JYXxLhTxk2dXumEATmrULXl4 /ZBCJ5szqvhCArMCg5/dUAhA2Fp2j2jm8knh7+I2IIOX62UThDQiQRjwxvX2QDbB 8moAsEiGlOWw5SCkydXCu2l/a1O7xSZuU5lmggJa85xaCw/eQEOsHQD5lEi7YEHN VCTiV0+n4xLFniKLE1PfqS9xo7xqlZ4yq4YqJazCQIBd44siDlGh86Ck8oLjA5FK IgRyHRwNBPh1Tbg4WdGQUyms/gXeO1cldK4F/FPWPUOobKNR8VZwed++sxgf/ECE yWng6ckMNkknKZJDp4tXUp5f2D4Vjc4GSL9Aur+woNws+n2YV2xIwQ== =eI5K -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Frank Gadegast wrote:
Currently most abuse contact addresses are hidden in whois output remark fields in several non-standarized ways or do not even exist, because the real abuse-field is non-mandatory. There should be a standarized method how to contact responsible people to send abuse reports too.
My impression is that the irt object provide an unambiguous way to provide this information; if it is present.
Currently there is no control, if existing abuse contacts are still valid, working or incoming emails are beeing read.
The proposal doesn't ensure that the abuse mailbox is read or that the information is acted upon. That's not something that's easy to tell just by records of e-mail transmission. Many abuse mailboxes are monitored and acted upon but otherwise show no external signs of a response.
The real abuse email address of any RIPE member should be hidden by the abuse monitor system.
I don't think that's a good idea. There are legitimate reasons to want to know the real abuse email address, or you may simply not want to relate a report to a specific IP address.
RIPE NCC could e.g. arrange for security training cources and invite members with a very high reporting rate according to the amount of allocated IP addresses.
What do you propose as a metric for this? The raw volume of reports, or reports per IP address, whilst obvious are not too helpful. I'm sure that at specific time there's always a host on our network causing lots of reports to be sent to our abuse mailbox, but that's not a sign that we're running the network badly but simply that our network is very large. You could look at reports averaged across address space but that'll count unfairly against large networks using address translation. We have this problem here where a few IP addresses generate unusual levels of reports, but not when you take into account that those few addresses have many tens of thousands of computers and users behind them. I'm not suggesting it's not possible, but that this is a very difficult question that we've had to think about in the past, and I'd love to hear the answers :) More useful to us is when we talk to our customers about activity and realize that something 'hinky' is going on (http://www.schneier.com/blog/archives/2007/04/recognizing_hin_1.html).
Their should be no anti spam systems implemented on this server to ensure that every incoming email gets forwarded. Anti spam systems should be up to the member. ... 6. Disadvantages It is likely that spammer will misuse the new general abuse adresses massively. Anti spam methos needs to be implemented at the members side.
The stats that RIPE would gather, in no way would correspond to the actual reports ending up in front of the abuse handler, as the RIPE stats would include spam sent to a.b.c.d@abuse.ripe.net
Furthermore, RIPE NCC should monitor, if the members abuse contact address generates errors, bounces or other problems like "User unknown" or "Mailbox full". If the members abuse contact address is not valid anymore, it could be reset to the members hidden main email address, and the member could be informed about the problem in other ways (letter, phone call aso).
That could be a good idea. You'd have to have a think about how many man-hours that'd involve though.
The system does neither have to define or decide what spam or abuse is, because it only forwards abuse reports to the responsible person. It is likely that any incoming email is a description of a real abusive problem (except incoming spam).
Not only incoming spam, but it also would include all the other stuff that ends up in our abuse mailboxes but isn't "abuse". I'm thinking of people wanting us to step into personal disputers, or people who are just very confused as to what we can help them with ;)
This all can ensure that incidents are really reported by the abused users (and not beeing ignored or forgotten because its to much work to report incidents) and that reports will be read by the right and responsible person.
No, it'll just ensure that the reports end up being delivered to an mailbox. Even if they then end up being read, that's not going to be enough is it?
This will finally increase the awareness of any RIPE member about the problems his end users or misused servers may cause and will hopefully force any member to implement methods to monitor there own servers and/or dialin users to improve the detection of misused services.
I'd like to see RIPE members being more aware of the irt object. James - -- James Davis +44 1235 822 229 PGP: 0xD1622876 JANET CSIRT 0870 850 2340 (+44 1235 822 340) Lumen House, Library Avenue, Didcot, Oxfordshire, OX11 0SG -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLveY6hZi14NFiKHYRAqBIAJ9xQf07MrEaw3sspxd8NpBCkQoh9QCfa7Mw 1wqUA/ZUML/crgpi/visJHo= =MdAe -----END PGP SIGNATURE----- JANET(UK) is a trading name of The JNT Association, a company limited by guarantee which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG
On 8 Apr 2010, at 6:29, Frank Gadegast wrote: [...]
This document describes the implementation of an abuse monitor system at RIPE NCC. Its intention is to ensure working abuse contacts on the members side and to improve the awareness, responsiveness and work flow for abuse reports for the reporting (and abused) internet users and the RIPE members (owning the misused services).
I still don't understand how a system similar to the one proposed would compel members to deal with abuse reports. Presumably a member could just send all their incoming abuse reports to /dev/null. As I understand it, the people who want to receive reports to help them keep their networks clean already publish IRT objects. A system like the one proposed would add an extra layer between the complainant and the relevant network and could well become a target for abuse itself. I am not sure how it would make network managers want to deal with abuse complaints that they are currently ignoring, though. Can you expand on that? Thanks, Leo
Hi all, For various reasons - allready mentioned by some people - I cannot see much benefit coming from this proposal. Most important seems the fact that it will not solve the problem of ISPs not having/reading/treating abuse email contacts. On Thu, Apr 08, 2010 at 03:29:44PM +0200, Frank Gadegast wrote:
4. Description RIPE NCC should implement a mailserver able to receive emails in the form of
IP1.IP2.IP3.IP4@abuse.ripe.net (example)
In case this proposal is going to be continued PLEASE make it IPv6 compatible. cheers, j. -- j.hofmüller http://users.mur.at/thesix/
On Thursday 08 April 2010 15.29, Frank Gadegast wrote:
Dear all,
please discuss and comment to following draft proposal ... (and please forgive but correct my english, bad formatting or terms)
Kind regards, Frank
<suggestion removed to save some space>
Frank, i find this initiative excellent as a startingpoint, in fact it would be quite workable as-is. Good work. But we must remember that most spam comes from West ( us and latin america) and east. This is outside RIPE's authority. Implementing successful abuse/spam countermeasures will however serve as an example for both west and east, europes example will have effects on opinions worldwide ( providing the get real effects of course). I'd say "YES" to your proposal. -- 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. )
peter h wrote:
On Thursday 08 April 2010 15.29, Frank Gadegast wrote:
Dear all,
Hi Peter,
please discuss and comment to following draft proposal ... (and please forgive but correct my english, bad formatting or terms)
Kind regards, Frank
<suggestion removed to save some space> Frank, i find this initiative excellent as a startingpoint, in fact it would be quite workable as-is. Good work.
But we must remember that most spam comes from West ( us and latin america) and east. This is outside RIPE's authority.
Thats right, but remember, that most RIRs are doing the same in the end anyway, If there is a new idea at on RIR, it is likely that the others make the same, maybe slightly different to their regional needs.
Implementing successful abuse/spam countermeasures will however serve as an example for both west and east, europes example will have effects on opinions worldwide ( providing the get real effects of course).
I'd say "YES" to your proposal.
Great and thnx again. Kind regards, Frank -- 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 ====================================================================== Public PGP Key available for frank@powerweb.de
Hi, to be honest I like the idea, but unfortunately I'm sure that it will not work. 3.3 reasons therefor: 1.) We have a few customers in the RIPE region and they receive several million reports per day. There is absolutly no way to route all the complaints over a centralized system. And the number of reports is increasing every day, which is a good thing in my opinion. 2.) Centralized systems are dangerous. Spammers are not stupid and if they see that such a system is doing a good job, they will attack it. We have seen that even in smaller company enviroments. They will be able to kill this system within days and everything is getting worse. 3.) Even with a huge undestroyable system we will not be able to get good metrics. As mentioned in point 2 spammers will attack this system. But only the ISP itself can decide if a message is spam or just a spammy looking complaint. That means everything has to be forwarded even if it is 50% spam which opens the door: a.) to aspers selective ISPs with spam attacks on single netranges. b.) kills the abuse department of smaller ISPs which do not have an automatic system. I would like that approach, because it would generate lot's of new customers for our Abuse Handling Framework. c.) makes metrics absolutely unusable. I think this idea is great, but it is not working. I will wait for the result of this discussion and propose the same policy proposal which was accepted by APNIC, is in discussing at AfriNIC now, to the RIPE policy group. Thanks Tobias -- abusix.org Am 08.04.2010 15:29, schrieb Frank Gadegast:
Dear all,
please discuss and comment to following draft proposal ... (and please forgive but correct my english, bad formatting or terms)
Kind regards, Frank
--------------------------------------------------------------
DRAFT: implementation of an abuse monitor system (draft RIPE proposal)
Abstract This document describes the implementation of an abuse monitor system at RIPE NCC. Its intention is to ensure working abuse contacts on the members side and to improve the awareness, responsiveness and work flow for abuse reports for the reporting (and abused) internet users and the RIPE members (owning the misused services).
Contents 1. Introduction 2. Goals of an abuse monitor system 3. Requirements 4. Description 5. Advantages 6. Disadvantages 7. Enhancements 8. Outlook
1. Introduction Taking in account the amount of spam and other abuse currently happening every day, there is a need to ensure that ISPs and other organisations are aware of the problem their customers and end users can cause for others.
The current procedure of having non-mandatory abuse contacts in whois output is causing several problems for the incident reporting side as well as for the receiver.
RIPEs member should be responsible for the abuse their customers cause, like this is enforced by law in many countries already.
2. Goals of an abuse monitor system Currently most abuse contact addresses are hidden in whois output remark fields in several non-standarized ways or do not even exist, because the real abuse-field is non-mandatory. There should be a standarized method how to contact responsible people to send abuse reports too.
It should be possible to to send abuse reports to a standarized email address, because whois queries are limited. The system should bypass whois queries, so that reports can be automated.
Currently there is no control, if existing abuse contacts are still valid, working or incoming emails are beeing read.
The real abuse email address of any RIPE member should be hidden by the abuse monitor system.
Finally a monitoring system should be able to messure the amount of incoming reports for any RIPE member. This will enable RIPE NCC to help members to become more aware of security breakouts or help members that are not aware of the problems they cause.
RIPE NCC could e.g. arrange for security training cources and invite members with a very high reporting rate according to the amount of allocated IP addresses.
3. Requirements RIPE NCC should enhance the member section with an extra abuse contact field. This field should be filled at startup with the main email address of any member automatically, but should be editable for the members.
4. Description RIPE NCC should implement a mailserver able to receive emails in the form of
IP1.IP2.IP3.IP4@abuse.ripe.net (example)
Incoming emails to these addresses can be treated as incoming abuse reports and will be forwarded to the members internal abuse contact address (non-public), after the mailserver finds the correct member by looking up internal allocation tables.
The amount of incoming emails for every member will be logged and should create internal statistics for RIPE NCCs internal usage.
Their should be no anti spam systems implemented on this server to ensure that every incoming email gets forwarded. Anti spam systems should be up to the member.
Furthermore, RIPE NCC should monitor, if the members abuse contact address generates errors, bounces or other problems like "User unknown" or "Mailbox full". If the members abuse contact address is not valid anymore, it could be reset to the members hidden main email address, and the member could be informed about the problem in other ways (letter, phone call aso).
5. Advantages The system does neither have to define or decide what spam or abuse is, because it only forwards abuse reports to the responsible person. It is likely that any incoming email is a description of a real abusive problem (except incoming spam).
The described system would make it very easy for any ISP or private person to report received spam, hacks or other abuses directly to the responsible RIPE member, without having to know its name and without having to know how to use whois. Reporting systems could be easily automated without having to query whois.
The ISP or RIPE member can easily change and control his internal abuse contact address without having to update several objects in RIPEs database.
RIPE NCC can ensure that all alocations have a working abuse address.
This all can ensure that incidents are really reported by the abused users (and not beeing ignored or forgotten because its to much work to report incidents) and that reports will be read by the right and responsible person.
This will finally increase the awareness of any RIPE member about the problems his end users or misused servers may cause and will hopefully force any member to implement methods to monitor there own servers and/or dialin users to improve the detection of misused services.
This will hopefully reduce the amount of spams and abuse worldwide.
Finally this will maybe influence other RIRs to implement similar systems.
6. Disadvantages It is likely that spammer will misuse the new general abuse adresses massively. Anti spam methos needs to be implemented at the members side.
7. Enhancements The system could be enhanced with addtional services easily on RIPE NCCs side, after implementation and a test period of the system. More detailed statistics could help improving the awareness at the members side.
Enhancing forwarded abuse report with an feedback link could help to categorize incoming reports. Members could then visit a ticket system to back report incoming reports as "spam", "incident" or "wrong report" (like popular spam blacklist like SpamCop are doing this already), add comments like "missing information", "incident currently under investigation" or "incident solved". This could help members to track reports and incident easily without having to implement a own system (what could be very interesting for smaller ISPs). Finally this would allow the reporting internet user to receive feedback to ensure that his input is valuable, important and taking care off.
8. Outlook Standarization of a general abuse address will be another step to the standarization of an abuse report format, wich are currently in process. This could lead to open source implemantations of spam detection solutions that include standarized reporting features. Standarized reporting could also be included in other monitoring and detection software, like Intrusion Detection Systems or Antispam Solutions.
Author: Frank Gadegast Company: PHADE Software - PowerWeb Contact: frank@powerweb.de Version: 0.1 Date: 08.04.2010
participants (7)
-
Bradley Freeman -
Frank Gadegast -
James Davis -
Jogi Hofmüller -
Leo Vegoda -
peter h -
Tobias Knecht