I just talked to Greg, he said something that might help would be to add "FWD: " before the forwarded message. Or possibly "Forwarded from XXX.XXX.XXXX: "
I can confirm that my system did forward the message without any modifications at all. (my employee knew what it was because he knows all text messages from that number are forwards)
This sounds like a highly problematic solution. If twilio actually greenlights spam that starts with "Forwarded from XXX.XXX.XXXX:" as Greg suggests, you can be sure actual spammers reading this thread will catch on and start sending spam texts with a header intro like that, probably by EOD today.
I think one of the key contexts here is being forgotten:
These are all internal messages. Someone cannot use our system to text random people. It's literally one person seeing them. We're a local service company. We're not SAAS or something like that. It's just people messaging us "Hey can you guys come Thursday?"
This would be like if you signed up for a VOIP provider for your business phones and they suspended your account because someone sent you a phishing text message.
With due respect, you are the one ignoring key context:
From the employee's carrier perspective those are external messages originating from you.
All that Verizon/T-Mobile/at&t see is spam coming from you, they don't know about the employer/employee relation. So when those carries complain to your carrier, your carrier has little options but to lock you.
Ok so are you saying that Twilio cannot be used to rely messages from company phone numbers to employee cells phones?
I would understand if this was an edge case, but my understanding is this is a quite common and a core use case. I'm pretty sure this exact use case is in their basic tutorial.
All the recipient's carrier knows is they see a spam or phishing message originating from Twilio, and (profess to) have a zero tolerance for spam/phishing. They have no idea about context of the "forward to consenting employee" use case or any way of validating it.
If there is any possibility that those messages could be interpreted as spam, that doesn't seem to be a valid use case for Twilio (any more). You could forward the message over some channel other than SMS to the employee (like email, or a custom solution).
I think you are right that it's not a valid use case anymore, even if they still assert that it is, because the reality is that it caused this problem. Even if they had responded to me immediately, my phones would have been shut down overnight.
Also, I was looking into the pricing a few months ago and its kind of expensive because I'm actually paying for two text messages: One for the incoming one, and one for the forwarded one.
The code has been working this way since maybe 2015, possibly before (its been so long, I can't remember). I've been using Twilio since I think 2010. I started out just doing call forwarding and later on added text messaging when customers started to expect to be able to text message us.
At the time, it was a core use case. There was a tutorial and everything "Forward text messages to your phone in a few lines of code".
I can confirm that my system did forward the message without any modifications at all. (my employee knew what it was because he knows all text messages from that number are forwards)