> From Twilio's system right.

Do we know this? I don't think OP has clarified - they just said it goes to an "employee's phone number", which makes me assume it goes out to their personal phone number which is probably not on Twilio. If that's the case I'm wondering if Twilio received some kind of complaint from the employee's carrier that they forwarded the message too, rather than detected it themselves.

It is simply against the ToS to send spam over twilios network. Objectively this is what OP is doing. You are allowed to receive spam maybe your core business even depends on getting spam numbers or analyzes the spam for phishing links itself. You can receive and ingest it in anything you want you just can't send it over twilio yourself. Sorry this is not a design flaw this is just a bad workflow.

This is absolutely a Twilio design flaw.

It's an incredibly common use case to forward text messages from one incoming line to another number that is controlled by your company, and 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.

It's the same exact thing that you might do if you have a [email protected] email address; it probably sends incoming emails to a number of different inboxes, even if those incoming emails are spam (and even if there actually is a spam system in place that might block some percentage of incoming messages, and Twilio doesn't even provide that.)

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?)

> Objectively this [send spam] is what OP is doing

No, no it is not. These are legitimate consentual messages, regardless of the content. Please stop applying mechanical interpretations of obtuse rules and pretending it's some profound wisdom. Twilio and the rest of Big Tech are already doing this enough, thank you.

Ultimately I think this problem is the end game of companies finding ways to absolve themselves of any liability through contracts of adhesion. When there is no downside to harming 1% of your customers besides losing 1% of revenue, biasing for egregious false positives makes financial sense. Same thing with terrible customer service policies crafted around keeping costs down, that prevent easily correcting these terrible automated decisions. About the only thing one can do is signal boost so others stay the fuck away from services built on broken assumptions, hopefully turning that 1% into maybe 10% where it starts to hurt them and they're once again encouraged to do competent system design.

Not for the carrier twilio is sending out these message to.

No these messages are not spam there either, because they are not spam period.

What you might mean is that the carrier's draconian probabilistic anti-spam system incorrectly categorizes them as spam. And that this causes a practical problem for Twilio, which lacks any recourse against said carrier's incorrect classification. In other words, a similar problem to what OP is complaining about, one hop away.

You're doing nobody any favors by elevating technical details out of their narrow context and stating them as an unassailable description of high level behavior.

These messages are subjectively spam for the platform you use if they specified it in their ToS you have no right to force them to serve you.

Yet again you're just stating a technical description as if it implicitly justifies the state of things. Nobody here is confused about how Twilio can legally do this or how market incentives encourage them to do so.

We're discussing a higher level behavior and what ought to be. And getting a critical service pulled out from under you based on overzealous unaccountable spam filtering is certainly not what ought to be.

No we are not. You are.