cogent spamming directly from ARIN records?

This morning I received an email from someone at Cogent asking about an ASN I administer. They didn’t give any details, but I assumed it might be related to some kind of network transport issue. I replied cordially, asking them what they needed. The person then replied with a blatant spam, advertising Cogent IP services, in violation of the U.S. CAN-SPAM Act’s prohibition against deceptive UCE.

I believe they got the contact information from ARIN, because the ARIN technical POC is the only place where my name and the ASN are connected. I believe this is a violation of Cogent’s contract with ARIN. Does anybody know how I can effectively report this to ARIN? If we can’t even police infrastructure providers for spamming, LIOAWKI.

-mel beckman

Mel, I will reply to you off list. Thanks.

compliance@arin.net

Refer back to an email John Curran sent to this list on Jan 6 2020 , “Suspension of Cogent access to ARIN Whois”

John,

Thank you for your guidance!

-mel

Tom,

Thanks for that pointer! apparently cogent has a history of abuse.

-mel

<blush> dang auto correct! I should’ve caught that bad change. what I meant to say, was:

LAWKIWBO.

-mel

Apparently?

In other news, apparently bears have been using our National Forests as their personal toilets for decades.

Jay,

Apparently my sarcasm was too subtle :slight_smile:

-mel

Hurricane has been doing the same thing lately... but their schtick is to say that "we are seeing a significant amount of hops in your AS path and wanted to know if you are open to resolve this issue".

compliance@arin.net is about all that can be done, other than public shaming!

Other outfits have been spamming using the nanog attendees list, but I guess that’s not as bad as the continued scraping of ARIN records, so I won't call them out... yet, at least. :blush:

I get what HE are trying to do here, as I am sure all of us do.

The potential fallout is a declining relationship with their existing customers that bring other downstream ISP's behind them. Contacting those downstream ISP's to "resolve this issue" puts them at odds with their existing customers who bring those customers in already.

There is a chance they dilute their income because, well, smaller ISP's will not be keen to pay the higher transit fees their upstreams pay to HE. Which means that HE are more willing to be closer to eyeballs than they are maximizing margins.

Is the loss of customer trust worth the transit-free glory?

Mark.

Hurricane has been doing the same thing lately… but their schtick is to say that “we are seeing a significant amount of hops in your AS path and wanted to know if you are open to resolve this issue”.

I get what HE are trying to do here, as I am sure all of us do.

The potential fallout is a declining relationship with their existing
customers that bring other downstream ISP’s behind them. Contacting
those downstream ISP’s to “resolve this issue” puts them at odds with
their existing customers who bring those customers in already.

There is a chance they dilute their income because, well, smaller ISP’s
will not be keen to pay the higher transit fees their upstreams pay to
HE. Which means that HE are more willing to be closer to eyeballs than
they are maximizing margins.

Huh?

In all my decades of time in the network industry, I have never seen a case where a smaller transit contract had lower per mbit cost than a larger volume contract.

I would expect that HE would make more money off 10 smaller customer transit contracts than one big tier 3 wholesaler transit contract.

It seems like a win-win for HE:
more customer revenue and shorter hop-count paths they can advertise to the rest of the world.

Is the loss of customer trust worth the transit-free glory?

When it’s offset by more revenue?

Sure seems like it. :wink:

Mark.

Matt

That's my point.

Smaller ISP's will get better per-Mbps rates from their direct upstreams than they would from HE/Cogent. The rates they'd get from HE/Cogent would be to HE's/Cogen's favour, and not to the ISP's favour.

So if the goal is transit-free glory vanity, HE/Cogent would have to take a bit of a haircut which they "could" make up in contract length.

Just another way to skin the cat.

Mark.

Has anyone replied?

If this is a peering request, not sure that is a bad use of the AS contact info.

If it is a sales pitch, then yeah, that’s a problem.

Patrick,

It’s a sales pitch, and ARIN acknowledges it violates their terms and has taken action.

-mel

In this case, it came from a person with the title of “Global Account Manager”. Unless sales people are handling peering requests all of a sudden, it’s definitely a sales pitch.

Congrats! LIOAWKI is a hapax legomenon in DuckDuckGo’s search results! Could you please tell me & the list what it means?

So is LAWKIWBO, which is the correct acronym mentioned downthread.

I'd suggest everyone use an alias unique to ARIN for your POC and/or public email. Makes it super simple to verify where it was sourced from.

(and yes I've got the same spam)

this sort of thing (provider X scrapes Y and mails Z for sales leads)
every ~18 months.
the same outrage and conversation happens every time.
the same protection mechanisms are noted every time.

Is there a reason that: "killfileand move on" is not the answer
everytime for this?
(why do we need to keep rediscussing it)

* morrowc.lists@gmail.com (Christopher Morrow) [Tue 03 Oct 2023, 18:29 CEST]:

this sort of thing (provider X scrapes Y and mails Z for sales leads) every ~18 months.
the same outrage and conversation happens every time.
the same protection mechanisms are noted every time.

Is there a reason that: "killfileand move on" is not the answer everytime for this?
(why do we need to keep rediscussing it)

It's a vicious circle: provider scrapes operational addresses and spams them, providers stop putting useful addresses in public databases to avoid spam, everybody who needs to find operational contacts in a variety of situations loses in the end.

We keep discussing it because we care about keeping the internet running. It's similar to why we keep looking for new security holes in existing software: we don't stop because inevitably we'll find more so it's a lost cause, we keep looking because inevitably we'll find more so the product becomes more secure.

  -- Niels.