As I pointed out here yesterday, several blocks currently being routed by AS56630 have reverse DNS set for them that makes it altogether apparent, to anyone with experience in these things, that the blocks are in use by snowshoe spammers: https://bgp.he.net/net/185.104.193.0/24#_dns https://bgp.he.net/net/185.104.194.0/24#_dns https://bgp.he.net/net/130.0.88.0/22#_dns https://bgp.he.net/net/194.29.52.0/22#_dns https://bgp.he.net/net/194.156.96.0/22#_dns https://bgp.he.net/net/213.183.47.0/24#_dns (The reverse DNS settings on that last block are actually just some stale leftovers that have never been changed since 2017-07. And the domain names shown are all long dead, and the spammer in question most probably vacated the premises ages ago.) Perhaps not coincidentally, all of these blocks have had new route objects created for them in the RIPE data base within just the past six months or so. The first group above belongs to a company that is located in the country of Georgia. The second group above belongs to a company or individual located in Germany, and that has its/his own ASN, i.e. AS15701, which is actively announcing several routes as we speak. The third group above belongs to a set of organizations in Iran. I have so far not been able to get responses via mail from any of these organizations, even though I have not sent all of them inquiries, asking them if they have authorized AS56630 to route their blocks for them. (I suspect that they have not.) I have however received today a respones to my follow-up inquiry which I sent via email to "Melbicom Abuse" <abuse@melbicom.net> yesterday. In that response, whoeevr is behind that role account finally did agree that AS56630 was improperly allowing route announcements for the reserved ASN AS65000 to leak due to an error on their end, and that corrective action has been taken. That answers one of the two questions I asked to people who are running AS56630. The other question I asked is whether or not AS56630 had LOAs for the blocks it is routing on behalf of Iranians and Georgians. This is the relevant part of the response that I received today from <abuse@melbicom.net>: "Regarding your 2nd question, we do not request LOA, we rely on RIPE database authorisation features. If customer looks suspect, we dig deeper and perform additional checks." Can someone please explain to me what this person means when he/she/it says that melbicom.net "relies on RIPE database authorisation features" ? What could that possibly mean? Regardless of whetever <abuse@melbicom.net> intended that statement to mean, it appears that melbicom.net itself created matching route objects for several of the spammer snowshoe blocks mentioned above... routes for blocks that they themselves clearly do not own. And these route objects were all created within the last 6 months or so. Here is an example: =========================================================================== route: 194.29.52.0/22 origin: AS56630 mnt-by: MELBICOM-MNT created: 2018-08-30T10:04:39Z last-modified: 2018-08-30T10:04:39Z source: RIPE =========================================================================== So, this leads me to a question: Wasn'gt there supposed to have been a change, in both policy and procedure, that allegedly took place some time ago now, where the Powers That Be were no longer going to allow route objects to be placed into the data base unless and until positive and affirmative consent was obtained from the purported IP address block registrants? Was that actually implemented? If so, then how is the identity of the "actual" registrant of any given IP address block being validated or verified under this new regime? Is it possible to fool the system by wearing a set of fake plastic fingerprints? Regards, rfg