[AfriNIC-rpd] abuse contact information in whois database (AFPUB-2010-GEN-002)

[Tobias Knecht]

>> What about a mandatory abuse contact object and a DNS based list?
> 
> It all depends how "mandatory" is acted on outside the context of this
> policy proposal.  I'll stay out of this for now.

Does that mean I won? ;-) Just kidding. :-)

> A DNS based list is a hack.  I doubt such a specification will be
> standardized.  Does any RIR serve the data through DNS?

No not so far, but does that mean that it is wrong? DNS is easy to use
and was just an example for some easy to use service that should be
offered by the RIRs. The approach of RIPE is pretty cool as well, but I
think it is much more expensive than a dns query.

>> If the RIR is offering this service, why should it be mined. It would be
>> much easier to generate a daily rbldnsd file and offer it that way, than
>> offering bulk data and or an abuse finder API like RIPE is doing at the
>> moment.
> 
> You'll have to offer two or three formats instead of one for rbldnsd
> only.   The world seems to like Web services such as REST these days. 
> It still make sense to have bulk data access if you are offering
> services that depend on this data.

In my opinion - no. DNS is scaleable, fast, much more robust than
anything else and a software which uses the abuse contact information
and is not able to do a DNS query is kind of funny.

>> To be honest, FBLs are not. FBLs are nice to tell a marketing company
>> they should unsubscribe the users, but the false positves rate is way to
> 
> Receivers of these abuse reports will face the same problem with false
> positives.

Absolutely, but this again has something to do with the trust level. I
can even trust one FBL more than another FBL and trust the data coming
from abusix less or more. This is something that has to be decided by
every abuse department on their own. I know that the customers of us,
are not trusting the FBL that much, because the false positives are too
high.

>> high. Reports from Honeypots, real spamtrap hits, ssh attacks, sql
>> injection tries, phishing websites are much more reliable than a FBL
>> could ever be. Our customers do not even order FBLs for exactly the
>> false positives problem.
> 
> You still need FBLs for IODEF and MARF or else it is like sending
> reports into the night.  Some ISPs within the AfriNIC regions do respond
> quickly to reports even if it isn't from a FBL.

Absolutely, I never doubt the existence of FBLs. They are good as a
additional measurement.

>> By the way, last week on huge anti spam summit in Barcelona, the biggest
>> issue was a to find a solution against outgoing spam and almost every
> 
> That's the body that has port 25 blocking as a best practice. :-)

Exactly and I can not tell you how deeply I hate this best practice. But
the good thing is, that the ISPs are not willed to block port 25,
because they know that than the compromised systems will do other
abusive stuff. They want to fix the problem by using the easiest
generatable report type spam and clean their network. So this is a
really good way.

>> ISP was agreeing, that automatic abuse handling and direct escalation
>> would be the best way to get things done.
> 
> And that's why they would like the format to be standardized.

That is why they are doing ARF. Thats why we and some other ISPs in
Germany started doing an extension for ARF, which is able to fulfill the
requirements of other kinds of reports. Shortversion: Yes.

>> The more complaints you are receiving the easier it is to handle things
>> automatically. And the only thing you have to do at the end, decide
>> which reporter is how trustworthy and not clicking through a ticket
>> system all day long.
> 
> And that's why this proposal is part of a picture.  It's much more work
> to automate if you don't have standardized formats and protocols to feed
> into your ticketing system.

Absolutely. And that is something we are working on as well. ARF,
Extension of ARF.


Thanks,

Tobias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <https://lists.afrinic.net/pipermail/rpd/attachments/20100617/605c5ee2/attachment.sig>