ABUSIX

We check the whois data for every IP range (inetnum), not domain and not single IP, since we are looking for the network owner that hosts the abuser. If you have no special IRT-object or POC, we look for the abuse-mailbox object. If we are still unable to find your abuse@ role account, we search the remarks/trouble/descr fields for abuse@/security@/cert@/csirt@ strings. After that we use the Admin-C or Tech-C address. If nothing is found at all, we use the first e-mail address hit in the whois record. To avoid receiving our reports on the wrong account, please keep your whois record updated accordingly.

As an APNIC member please have a look at this.
As an AfriNIC member please have a look at this.
As a RIPE member please have a look at this.

If you receive reports for IP addresses outside of your range, it is likely that an error has occurred. If so, please contact us and we correct the ranges we find in our system. Please be sure, that you add all needed information (ip-address, net-range, correct and/or incorrect abuse contact) in your request. Sorry for any inconvenience this might have caused.

There is a set of reasons for doing so:

• We figured out that about 80% of 2nd or 3rd level ranges contain abuse addresses located at freemail providers. The freemail providers block reports because they contain spam, which is quiet normal for a spam report. So the reports never arrive at the right place and we destroy our IP reputation by sending reports about “spam”.

• We also figured out that most of the Operators of 2nd or 3rd level ranges do not understand what to do with these reports. We received tons of questions and were asked to provide support while we feel that it is not up to us to provide support services for your customers.

• You can take appropriate measures , e.g. inform and/or lock your customers and by this help him to clean up his private infrastructure.
  We feel that it is very important that you see what is going on in your network, as every once in a while the customer is not responsible for the problem. Sometimes it is also a security problem in the infrastructure that can only be fixed by you. Eventually we can help to make your network safer than it already is.

• Last but not least it is a big challenge to get all the needed abuse contacts from the whois servers. All the RIRs restrict access and make it impossible to query every single address. Therefore we have to cache on a very high level base. As soon as RIRs decide to offer abuse contact API which is fast and can be used unrestricted, we will change this. RIPE started the AbuseFinder Tool project which looks pretty promising.

Abusix has a huge network with several domains and thousands of email accounts. The spamtraps we generate within this network are administrated entirely by us. We do not use traps from other parties.
The email addresses and the domains have never been used for any purpose other than for traps. No signups or subscriptions have ever been made with these addresses. Therefore, every email that hits these traps is a 100% spam. Senders that send to these addresses have likely found the domains registered within the domain whois, and then automatically created a range of similar email addresses, and started to send. This spam technique used by spammers is called “dictionary attack”. Another way we use to spread email addresses are different types of harvester techniques. Regardless of the method, both identify non-permitted spam behavior in a precise and reliable manner.

• We believe that the Internet needs to be protected from senders of spam content. Spamming, like systems hacking, virus spreading or any other form of destructive behavior on the Internet does sentimental harm to the image of ISPs and diminishes the experience of the user on the Internet.
• We believe that spam is an issue that needs to be urgently addressed. Legislative bodies around the globe will soon engage in putting pressure on institutions that favor spamming by not addressing the problem in a satisfactory way.
• Consequently, we believe that ISPs need to take action in their role as link between senders and receivers of spam mails.
• We furthermore believe that current solutions to the problem of spamming try to fight the symptoms instead of the roots. Spamming is evolving continuously and solutions prevailing on the market only retard the problem while charging hilarious amounts of money.

By reporting every single spam mail to the network of origin, we grant ISPs insights into the extent of the problem on their networks. Sending reports in fixed intervals, e.g. daily reports, would trivialize the problem and distort the message we want to send.

We do not send spam to you, we are reporting spam originating from your network. If you use spam filters on your abuse@ role account, you will block reports about spam originating from your network. Consequently, you ignore reports about senders abusing your network’s authorized use policy. Filtering simply means that you are providing a safe haven for abuse, and run a spammer friendly network. Help us to keep the Internet clean and make it a good place to be.

We check the whois data for every IP range (inetnum), not domain and not single IP, since we are looking for the network owner that hosts the abuser. If you have no special IRT-object or POC, we look for the abuse-mailbox object. If we are still unable to find your abuse@ role account, we search the remarks/trouble/descr fields for abuse@/security@/cert@/csirt@ strings. After that we use the Admin-C or Tech-C address. If nothing is found at all, we use the first e-mail address hit in the whois record. To avoid receiving our reports on the wrong account, please keep your whois record updated accordingly.

As an APNIC member please have a look at this.
As an AfriNIC member please have a look at this.
As a RIPE member please have a look at this.

If you receive reports for IP addresses outside of your range, it is likely that an error has occurred. If so, please contact us and we correct the ranges we find in our system. Please be sure, that you add all needed information (ip-address, net-range, correct and/or incorrect abuse contact) in your request. Sorry for any inconvenience this might have caused.

Unfortunately sending aggregate reports does not serve the purpose of using the data set.

• ISPs using our data work with thresholds based upon different vectors of abuse. The more reports these ISPs receive, the faster they can detect and eliminate abusers on their networks.
• Our spam trap network is too large to handle everything with a single server. Aggregating and creation of consolidated data reports is not our mission; we provide spam reports in real time.
• As more companies use ARF reporting you will have to find a way to consolidate those reports in a way that best works for you and your network. We give you the raw event reports so you can respond to threats in real-time using the source event data.

If you are interested in ARF tools or a complete solution for your Abuse Department, have a look at our corporate site and the Abuse Handling Framework.

Sorry, no. We use the IETF standard "MARF". MARF is the Message Abuse Reporting Format for message related spam reports defined in RFC 5965. It is already used by many ISPs. Simply open the file with a text editor and you get all the information needed.

You will find in-depth information on how the reports are structured on the spamfeed.me website. If you are interested in MARF tools or an enterprise solution for your Abuse Department, have a look at the abusix corporate site and the Abuse Handling Framework.

Some general information about the Global Reporting can be found here. If you want to help reporting spam, have a look at the blackhole.mx Project.

(See also the information about x-arf on the project website. x-arf is intended to be used for all other types of abuse reports.)

We never reveal the domains or email addresses we use as trap domains or addresses; this would destroy the whole purpose of the methods we use to identify senders of spam. Headers should include everything you need to solve the reported problem. The method we use to munge messages is as follows.

• First, we select all recipient addresses within the header.
• Second, we munge the same addresses within the full header and message body.

If you are not able to resolve the identification of the recipient on your own, use encrypted X-Abuse-ID header.