This is not quite right. We aren't sending the messaged from the original number. As far as I know, that isn't really possible because we don't "own" that original number.
The business case of relaying inbound text messages to an employee's phone number should be a very common one and should not warrant an account suspension.
Yes I think you are right. But I don't think Twilio allows it unless I somehow register the number and authenticate that I own.
I could be wrong, but I think they have a way for me to register my cell number so I could "spoof" messages sent from it. But I would first have to prove to them that I own the number.
The fact is that you are sending spam over twilios network even if it's just to your own employees. You are also saying it is not the first time it happens and you seem to have done noting to mitigate the problem at hand furthermore is it an attack vector for phishing against your company. The fact that you are not ingesting the text into another system is also a bit concerning how do you handle GDPR requests? If you are looking at the problem objectively twilio is in the right.
Here's what's happening, as I see it (corrections welcome):
1) Spammer sends spam to customer's Twilio number.
2) Customer has this number set up to forward incoming texts to employees.
3) Customer has no available API to detect whether texts are spam.
4) Twilio apparently can detect that this message is spam, but rather than simply dropping it at step 1, they're blaming the customer.
Sorry, there is no scenario under which this is the customer's fault.
If you have a business that deals with spam texts or if you host a honeypot for whatever reason you are allowed to do it. You are allowed to receive spam and do whatever you want with it except sending spam over twilio itself because it's against their ToS and to protect their own core business from getting their numbers blacklisted.
if twilio can not differentiate between inbound messages that are being forwarded and outbound messages that are created by the twilio customer then their service can't guarantee to be reliable because someone could basically create a DOS attack by sending spam to any twilio customer expecting that twilio will blame their customer and suspend the account.
It's not their job to differentiate they are just a carrier they scan for outgoing spam to protect their own core business and to not get blacklisted everywhere. Read the ToS they are pretty specific about it.
but then they are simply not suitable for the use case of forwarding inbound messages because the risk is to great that i'll get shut down just because i am receiving spam.
They're receiving the spam because it's sent to the customer.
They're sending spam when the customer asks.
They're also deciding that that customer is a customer no longer because of the choices that customer made with regards to sending spam, not receiving spam.
...or the complaints that caused the account suspension didn't come from Twilio. More than likely, the employee cell carrier noticed the spam and sent an automated complaint to Twilio, and then Twilio acted.
That doesn't excuse poor support, and the lack of resolution, but it changes a lot of the assumed processes.
And where are those people receiving the spam message in the first place? From Twilio's system right. If they are so good at detecting it circulating internally, why didn't they detect it and block it in the first place?
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.
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 support@example.com 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.
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.
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.
> 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.
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.
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.
I did mitigate the problem last time. I communicated with them and they told me it was fine.
I'm very curious. Is this a communication mistake? Like do you think I'm some big company that forwards text messages to random people?
Do you understand these are text messages being sent to one of like 3 employees at my small company? We are not generating outbound content or allowing anyone else to do so. Your question about GDPR requests makes me think maybe you have misunderstood the context.
If you have correctly understood the context, do you actually think I should have some kind of AI algorithm scanning these messages for Phishing?
I'm not sure I understand what your are suggesting or how you would have solved this problem? You would have just turned off the text message forwarding I guess?
Is that how you solve problems? You see a problem, then you destroy the thing that caused the problem, so problem solved? What do you do for a living with that type of cognitive approach? Are you an entrepreneur? Do you really run a business with that attitude? Are you en engineer? If so, when you are asked to make something work, do you just tell your boss "no" if you run into a problem that requires a creative solution? Are you a lawyer? Is your job to tell people what thing they cannot do, but not to help people do new things? That would kind of make sense...
> Do you understand these are text messages being sent to one of like 3 employees at my small company? We are not generating outbound content or allowing anyone else to do so.
The bit that you are missing is that this sort of thing is between Twilio and Twilio's carrier partners (sometimes mediated by third-party aggregators), and has nothing to do with you or your particular use case. Carriers have very low tolerance for third parties like Twilio sending spam to their customers. If carriers get pissed off at Twilio, they'll stop delivering messages coming from Twilio (or will impose other restrictions, like low rate limits, or perhaps charge more, etc.). Good carrier relationships keep Twilio running; bad carrier relationships cause all sorts of problems for Twilio and Twilio's customers.
The carriers do not know or care that the spam/fraud message you tried to send to your employee was just you forwarding along a message that some other random person sent to the Twilio number. All they would care about is that a spam/fraud message came from Twilio's platform.
Having said that, I too am disappointed in the policy of auto-suspension, and in how long it took for you to get the problem resolved, and that phone support is expensive to come by.. I think the right approach is to catch these things at send time and just refuse to send them. Sure, if some very high percentage of traffic is all spam, maybe an auto-suspension might be warranted, but I assume (hope) that's not the case for your account.
(Disclosure: I work at Twilio, though not on the messaging platform. My words & opinion here are my own, and don't reflect Twilio's stance on anything. Throwaway for obvious reasons; Twilio doesn't allow the rank-and-file to speak publicly about this sort of thing.)
Yeah I think we're on the same page here. I mean its a complicated problem, they're under pressure to solve it. They were backed into a corner by the carriers and suspended my account. Shit happens.
They just need a phone number. I actually called sales hoping I could plead my case and get them to connect me with someone. But I couldn't get connected with sales. If this was due to omicron and sales would have helped me, then this is truly an edge case.
It's not even good business practice you are paying for something that is essentially free if implemented in every other way. This is not creative this abusing a system going against their ToS and blaming them for your own failure. I am suggesting you ingest the received messages and distribute it any other way like a lot of twilio customers probably do. This is merely a hack and a bad one at that.
The business case of relaying inbound text messages to an employee's phone number should be a very common one and should not warrant an account suspension.