Constant Abuse Reports / Borderline Spamming from RiskIQ

Wed Apr 15 12:45:48 UTC 2020

[ Copied to Jonathan @ RiskIQ because I don't believed he's subscribed. ]

On Mon, Apr 13, 2020 at 11:14:11PM +0530, Kushal R. wrote:
>  All abuse reports that we receive are dealt within 48 business
> hours. As far as that tweet is concerned, it???s pending for 16 days
> because they have been blocked from sending us any emails due to the sheer
> amount of emails they started sending and then our live support chats.  >

There's a lot to unpack here, both for you and for RiskIQ.

Let's start with you.

Your home page says that you host over 100,000 web sites.
Your home page says that you have over 10,000 customers.
Your home page says that you have 24x7x365 support.

	(Which is wrong, by the way.  It's either 24x7 or 24x365
	or maybe 24x7x52 depending on what you're trying to express.
	There is no such thing as 24x7x365.  But let's press on:)

Given all that, why don't you have have a 24-hour abuse desk that is
empowered to act immediately on reports?  Do you not understand that --
as Suresh has pointed out -- the lifetime of many abusive activities
is measured in hours and that a 48-hour turnaround is far too slow
to be effective?

Your "about" page says that you're a leading web hosting company.

Alright then: *lead*.  Show us that you're one of the best at this.
Be one of the operations that we can point to and say "this is
how it's supposed to be done".

Because right now you're the opposite of that.

Also: don't use abuse.support at .  Use abuse@, per RFC 2142.  There is
zero reason not to go along with the standard.  If you want to alias
it internally fine, but at least get this rudimentary thing right.
*This is why we have standards*.

By the way: did you know that there are multiple COVID-19 scammers
who have set up shop on your service in past few weeks?  I'm very
curious as to why a "leading web hosting company" would allow such
a thing to happen, given that much of it's trivial to prevent.

And now: RiskIQ, it's your turn.

If an operation has exhibited the competence to read and implement
RFC 2142, and thus has a working abuse@ address that goes to some
combination of people and automation that deals with abuse reports,
then that's the one you should be using.  If it has a security@ address
then that's appropriate for those kinds of events.  And while there
are obviously cases where it's appropriate to send to both, it's never
appropriate to send this stuff to role accounts like sales@ or info@
or anything like that.  So: knock it off.

What about operations that haven't done that?  Okay, that's where you
look up their registered contacts.   There is of course no reason for
addresses like abuse.support@ when abuse@ will do perfectly fine for
everyone on this planet but if that's what has to be done, then (a) use it
and (b) try to convince them to use abuse@ like competent people who
have read RFC 2142 do.  We'll all be happy if you succeed.

Sending reports repeatedly may make you feel better by venting your
frustration, but it won't solve the problem.  (Now, if new information
arrives about a report you've already filed, then a supplemental message
is appropriate.)  Bombarding people either means you're (a) annoying
people who were already doing something or (b) annoying people who were
never going to do anything anyway.  So knock that off too.

Bugging people in live support chats is probably equally pointless.
So if you're doing that: stop.

	(Actually: given my experience over the past few decades "live
	support chats" are pretty much pointless, but that's a whole
	'nother problem and if I have to deliver *that* rant, I'll
	need scotch before noon.  So again, pressing on:)

As to naming-and-shaming on the web or Twitter or wherever: sure, if
you want.  But if you're going to do that then it's probably worth doing
a bit more formally, a la Spamhaus, with a web page that has a
unique URL and supporting evidence and an explanation and so on.
(Do keep in mind that operations like Twitter are transient and thus
not a good choice if you're trying to create a permanent record.)

---rsk