Hi Jordy,
On Tue 12/May/2020 22:21:11 +0200 JORDI PALET MARTINEZ via anti-abuse-wg wrote:
> El 12/5/20 19:26, "anti-abuse-wg en nombre de Alessandro Vesely"
> <anti-abuse-wg-boun...@ripe.net en nombre de ves...@tana.it> escribió:
>
> I think it is more useful instead of removing the address, marking the
> record as invalid, and this is being done if I recall correctly from RIPE
> NCC presentations. Because it may be a temporary failure of the address, so
> *not removing it* may bring it back in a subsequent verification.
If at all possible, I'd suggest to register a suitable RDAP JSON value for the
relevant remark type, at IANA[*]. That would allow automated tools to discard
the corresponding vcard entry.
ARIN write a remark, like so:
"remarks" : [
{
"description" : [
"ARIN has attempted to validate the data for this POC, but has
received no response from the POC since 2011-06-07"
],
"title" : "Unvalidated POC"
}
],
Such remark is not quite actionable, as it doesn't say which POC does not work
(recall there are various arrays of vcards, only some of which are tagged with
the "abuse" role.) Perhaps more importantly, it doesn't say if the invalid
nature of the mailbox was notified to the responsible organization, and such
notification acknowledged.
> [Jordi] I think both [actual validity and statistics] are useful to know. Is
> the address valid/invalid. If valid, is this LIR processing abuse reports or
> there is information escalated from the community that is not?
The latter datum is much more difficult to get right. I'd stick with an
invalid mark. If, say, email messages bounced since 2011, and the organization
was promptly notified and shrugged, a loud and clear mark is well deserved.
> [Jordi] Totally agree. I still think ideally, we should have X-ARF as the
> single way to do all the abuse reporting. Not sure if this could be also
> connected to provide feedback to DNSBL, but I'm not convinced RIPE NCC (or
> any other RIR) could do that ... very difficult to reach consensus on that
> at the time being. The stats might prove that on the long term and then we
> can change our minds.
The format, like the actual handling of reports, is one or more levels above.
As for a DNSBL, I keep reading that most data in the RIPE Database is public.
Are there API to browse its content? Is it possible to maintain a (filtered)
copy of it? If one could collect all the blocks whose abuse-c is marked as
invalid, she could then run a corresponding DNSBL. However, article 3 of the
Terms and Conditions for Data Access[†] seems to disallow just that.
Best
Ale
--
[*] https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xhtml
[†] https://labs.ripe.net/datarepository/conditions/basic
