Twilio is a carrier and nothing else by having zero tolerance against outgoing spam they are protecting their own core business. If OP or you in that regard would even glimpse at their ToS instead of just scrolling by when your business depends on it OP would not have made this user error.

What they're getting at is that Twilio clearly already has the capability of automatically detecting spam.

Why not open that capability to an API so that somebody who is operating some sort of forwarding service to run spam detection before forwarding?

Because they are not in the business of filtering spam they are in the business of receiving and delivering messages. The spam filtering outbound is to protect their own core service. Running spam protection for your own service is a lot different to offering spam protection for customers.

If you're going to hold people responsible for meeting a metric, you need to ensure they have a way of measuring the thing in question. To do otherwise is unreasonable by definition. If Twilio's definition of "sending spam" matched the OP's, where it's about sending messages the user did not agree to receive, then that would be reasonable. But instead it's something more intangible.

And like you say, they do need to prevent their system being used for sending spam. But if they're not going to provide a way for honest parties to avoid sending spam, they need to be reasonable about how they react to spam reports.

Exactly. Also I should point out that we weren't sending spam. It's just relaying the messages that we receive internally.

I would think sending spam would be more if we allowed people to sign up for a our service and then people used it to send spam.

But these are all internal communications.

You weren't sending spam just relaying is saying the same thing. Otherwise you could spam yourself and use that to send messages to a group of phones who could do the same thing. See the problem? I'm sure if this was a feature it was already exploited and patched.

Do you not see how spam protection for customers IS spam protection for your own service?

They already detect outgoing spam. Good customer service in this case would be to detect that a customer is attempting to send spam and blocking it and potentially notifying them about it.

Someone sending 50 maybe 100s of spam messages at the same time is going to get anyome automatically shutoff.

Sending one and the system might not have detected the spam. It's not visiting the link. But send many at once the system gets curious.

> it's impossible to tell at the point of receipt (when it's still in Twilio's network) whether it's spam or not before forwarding it on.

That OP mentioning "reprogramming the system so it doesn't forward messages" makes me think that they are receiving the incoming messages programmatically via webhook and then using Twilio API to send a new message with same text to new number (their employee).

In such a case, they do have a point in the process where they can implement some kind of filtering or processing (maybe stripping or obfuscating URLs?)