> Temporarily, I will re-program the system so that it does not forward text message content to my employees phone numbers.

I might be reading this wrong, but it sounds like you take inbound text messages to one number and then send outbound messages with the same content to employee phone numbers. Is that right? If so, that sounds like you're SENDING the spam messages in addition to receiving them. Regardless, it sounds like customer service needs to be improved, though.

I have set up a few twilio accounts like this where a business number blindly forwards to the business owner's personal cell, maybe some logic for business hours and holidays.

If twilio wants us to start filtering spam messages for these cases, they need to give us the API/tooling.

Or let us pre-register receiving numbers through an opt-in process.

I understand Twilio not wanting to be an open relay but the reported solution is not the way.

Yes or they could have just blocked the messaged before it hit my system. They are the ones that originally allowed the message to get to me. Then when I process it, they suspend my account.

Perhaps your employee's cell carrier detected the message as spam and automatically complained to what it saw as the source (twillio). From twillio's point of view they absolutely and unequivocally need to keep the carriers happy. If Att or Vzw simply blocks all twillio then twillio is dead. When faced with the choice of losing the entire company or losing your $600 a month it's pretty obvious why twillio has in place the automated system you recently chafed under.

It's probably a good idea for twillio to be more reachable to any paying customer, at least until a human employee makes the determination if the customer is a spammer.

I'd be really curious to know if this is what happened. Whats more interesting is he lives in Spain and his cell phone is on a Spanish carrier.

I also understand and agree with your argument about why they might have done what they did. But I still needed to counter with what I did in order to protect my business.

Rules for thee, not for me

Yeah this sounds highly problematic. Maybe in the meantime you can text links to your own portal instead. I.e. "New SMS received from +123... . Read it at: https://your-internal-infrastructure.com/sms/[GUID]" (maybe with a simple login so Twilio auto-fetch, if any, gets a benign page). That way there is no spammer-controlled message content (apart from the phone #) in the message you send. Or convert them to jpeg and send as MMS hoping that Twilio won't OCR that :D

Yes, these are very good ideas. Didn't even think of the JPEG one, very cool!

At a high enough volume, links will also get you blocked by carriers

Yeah, we pass all of our twilio messages to our staff via a special Slack channel.

Which pricing tier do you use? I've been thinking of starting with the for a while. Now we use a hodgepodge of Skype and WhatsApp

For which, Slack or Twilio? We have a basic twilio account, paying $1/mo for the phone number, and $0.1/msg or whatever it is.

On Slack, we have a paid account at the standard level, we've had that for years.

One note, both Google and Apple detect that our number is Twilio, and won't let us use it for 2FA, sadly (our original use case).

Or base64 encode the orginal message :p

It needs to be human readable, so maybe pig latin instead

If someone has already written a custom integration, how hard can it be to wire it up to a spam detection API? It sounds like the integration was sending spam (not intentionally of course), which none the less is a TOS violation.

If they can’t update the integration with spam filtering, then it seems like they should be using COTS software.

Is sending an employee a message they've elected to receive ever spam in some sense? If the reflection were to an arbitrary number then I'd say so, but simply forwarding to a specific number you're working with seems... Fine. Maybe it's different too if it's a solution you're selling, but even then that's somewhat between you and the customer.

I guess if twilio has negative impacts as a result of the perceived spam then that's a separate issue.

It was only spam on the inbound leg. On the outbound leg, it was requested and correct content.

I'm already using a spam detection API. But remember those things don't block all spam.

Also, there are other ways to solve this specific problem given that they are intent on auto-suspending my account in this type of context. I could relay the messages using a different platform as an example.

Thats not really the point though. Me not paying for the spam API or not using it when I relay messages internally to employees is not a good reason to shut my whole business down and not give me a way to contact them. This should be obvious.

While literally the case from what is described, it's clear that a consensual (by employment) message forwarding service happening to forward received scams/spams is quite different to actually scamming/spamming.

I guess it's unlikely that one can make this consent clear to Twilio, though, and if the messages aren't distinguishable then they might still get seen and reported as spam by the employee, with all the bad reputation that can cause for all involved.

It might be possible to register numbers with them, but they still could get in trouble with the actual carrier of the cell number so it might not even matter.

There are two layers here. 1) You're absolutely right that the account ends up texting out a phishing link which any automated system would rightfully detect as phishing (regardless of whether the recipient has "consented" to receiving the message - it still contains a phishing link). But that's not the real issue, which is 2) Twilio's response to detecting the sending of a phishing link (possibly more than one) is to disable an entire account with no timely recourse from the affected account holder who may be running a legitimate business.

I don't think anyone is arguing that Twilio was wrong to detect the message as spam. It's more that an unexpected side-effect of the customer's current implementation had outsized consequences. Similar unexpected friction with Twilio's anti-spam mechanisms are likely to occur again and they will cause outsized damage to this legitimate business or others if Twilio doesn't change their strategy.

As a text message recipient, I can't say I'm mad about Twillo's choice here.

I’m assuming you would be if your business was harmed through an honest mistake.

I'm the kind of person who would be mad at my choices in that case. If I failed to plan for that sort of thing it's on me. "What of someone sends abuse to my text message forwarder?" isn't all that out there of a question.

I should clarify that these messages are being relayed internally to me and like two other people. It would not be possible for someone to use out software to spam people. We are not a SAAS provider. We are a local service company.

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.

This is actually technically possible in the networks, at least here in Europe (generally).

However, obviously allowing such sms forwarding have to be done with care.

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.

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.

You are suggesting that a service that has no idea of what your business is should curate your data and "simply drop it"? yikes.

>>You are suggesting that a service that has no idea of what your business is should curate your data and "simply drop it"? yikes.

As opposed to just shutting down the customer because TWILIO forwarded the spam, that we already know that it can detect?

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.

Yes.

Umm... "curating the data" is exactly what they're doing when they ban the customer for forwarding spam that originated from their system.

twilio might not care but the carriers the messages get send to will.

The are otherwise curating the data and calling it spam on the outbound, so… yes?

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.

These are pretty different things.

Because they have made it pretty clear in their ToS that it is forbidden to send any form of spam over their network.

...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.

imagine that email providers would have used the Twilio way......

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?

> 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.

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 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.

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.

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.

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.

"If so, that sounds like you're SENDING the spam messages in addition to receiving them."

This is a bizarre and almost intentionally obtuse interpretation of the ops problem (albeit literally correct).

If I have built an auto-forward between two endpoints that I control (or at least have permission or authority over) I am not a bad actor in any capacity.

A much more appropriate workflow here would be for Twilio to cross-check this "spam" with inbound spam into twilio itself for some other number his account controls.

Which is to say, if a Twilio account originates a suspect message, first check to see that suspect message was sent, inbound, to it before auto-DoSing an entire business. This shouldn't be too tough, especially since these events probably occur in step with each other.

>If I have built an auto-forward between two endpoints that I control (or at least have permission or authority over) I am not a bad actor in any capacity.

I agree, though there are a few reasons why Twilio is sensitive to this.

I have almost a decade of experience in working with SMS and building apps for messaging, forwarding etc. In my case, I connected directly with SMS aggregators (who are the entities that actually connect carriers to each other), which is what Twilio does as well, so I've had to deal with many aspects of operating directly in this ecosystem.

For these messages that are being forwarded to other phone numbers, the messages are likely going through Twilio and out to the SMS network and physical carriers. I'm inferring this based on OPs comments which makes it sound like the forwarded messages are going to personal cell phone numbers. Even if there was a way to let Twilio know that those people want to receive those messages, there isn't a way to get the carriers on board with this.

In the US at least, the physical carriers have been standoffish with the virtual carriers like Twilio et. I have close to 10 years building similar things and in a company that connects directly to SMS aggregators just like Twilio does.

It's worth noting that long codes (i.e. traditional phone numbers) and short codes have entirely different cost structures. Since carriers get paid for messages on the latter, that's where they want automated messaging to originate. Since Twilio and others offer automation of long code messaging, they have to be very careful not to look like spam generation or consistently have too large an imbalance (i.e. one number generating far more messages than received). Carriers can and will block numbers (i.e. all SMS traffic from your number will be dropped) and, from my experience, they do it silently and with little recourse.

"If so, that sounds like you're SENDING the spam messages in addition to receiving them."

I should have clarified that this is from Twilio's perspective. They don't know that the recipients actually want to receive these messages, which makes them (by definition) not actual spam.

I'm actually very glad Twilio doesn't allow itself to be used for SMS spam. I hate SMS spam. Twilio doesn't know that these are "employees".

Twilio could fairly easily verify that the phone number owner consents: when setting up the recipient number, allow for double opt in - send a verification code that must be entered somewhere.

I worked at Twilio for 6 years, the carriers would never allow the thing you are asking for.

Twilio outbounds the SMS message over the carrier network. Part of that relationship is that Twilio has to prevent spam from entering the carrier network, or the carriers will ban the interconnect.

Here's the full workflow of this situation.

The inbound leg looks like this.

[Spammer] -SMS-> [Carrier] -SMS-> [Twilio] -HTTP-> [Customer]

The outbound leg looks like this (the customer initiates this in response to the HTTP request)

[Customer] -HTTP/TWIML-> [Twilio] -SMS (SPAM DETECTION HERE)-> [Carrier] -SMS-> [Employee]

All of these parties are separate entities, each enforcing spam blocking. Twilio is incentivized to not transit spam over the Carrier because the Carrier will get upset at Twilio. Twilio has no way to tell the Carrier "Oh, hey, this is spam, but the customer owns the number and they said they were cool with getting spam, please don't get angry"

But twilio happily accepts spam - at least according to the OP. The message flow according to the post is Spammer -> SMS -> Twilio -> Forward by Customer -> SMS -> Customers own number. So the correct place to check would be on the incoming leg.

Twilio's absolute responsibility is to protect carriers from getting SMS spam outbound. Twilio has no such contractual requirements from its own customers. Could they offer an addon service for this on the inbound side? Sure. But if you are using their service to send spam and phishing links outbund, they MUST filter that or risk their entire operation.

Spam detection is not perfect. Users may want to process their own messages unmolested inbound.

Twilio does not allow a user to "consent" to receive spam.

This is specifically covered in their ToS by the way.

"We never allow some types of content on our platform, even if our customers get consent from recipients for that content."

This is for the simple reason that a lot of folks are using Twilio for application to person / transaction messaging - and the key to delivery quality is to have no crap content going out.

If you operate an open relay for email - your IP address is going to be blacklisted very quickly. Same here, if twilio allows spam and fishing to go out, deliverability is going to go way down. Down the chain people don't know folks have "opted in" to the facebook phishing emails.

Sign up here for a code to win XXX. Then they send you the code (which is the twilio opt in code) and bam, you are in the spam list. All these things have happened on the email and other platforms side already.

> If you operate an open relay for email - your IP address is going to be blacklisted very quickly. Same here

This doesn't sound like an open relay (since the incoming message can't be forwarded to arbitrary destinations), this sounds like a mailing list. And if my mailing list was banned because someone else sent spam to it, I'd be upset too.

I'm making the point that sending messages on behalf of others DRAMATICALLY increases the risk that you will send low quality messages. Spam, phishing etc.

I'm more surprised that folks don't get that.

Twilio is clear. You are responsible for all messages you send using their platform. They are clear in their terms that this applies EVEN IF you allow others to use your service in ways that result in crap going out.

They DO NOT want spam or phishing messages going out from their numbers.

Everyone here saying this is "bad design", outrageous or whatever has not had to deal with spammers / scammers. This simple rule, you are responsible, full stop, for what you send using our API's, and if you send crap, we will suspend you - probably saves them from 90% of the abuse issues they would otherwise deal with.

Downstream, T-mobile, verizon etc - they don't care that the message was "consented" to by someones supposed "employees". When their customer reports spam coming from one of these numbers and if that number is verified -> game over for twilio

I get that just fine. I just disagree with it, and I disagree with the analogy to an open mail relay.

It’s definitely not analogous to an open mail relay in the slightest.

The whole point of an open mail relay is the 3rd party can send their crap through your servers to anyone they want to target. This scenario gives the spammer no control over who gets the message.

Twilio is being used as a message bus, and OP is simply trying to save the work of writing an app or a new UI on the employee’s phone to read a list of messages. It’s a pretty common use case.

Um, the twilio customer can be the spammer. They can send messages to anyone they want to target. Twilio IS running what is effectively an open rely.

To the degree twilio's business model depends on allowing its customers to send to whomever they want (which I assert it does), they CAN NOT let those customers send spam - full stop - end of discussion. If you don't understand why this is critical to twilio - I don't know what to say. MOST users do not want SMS spam.

Seriously, if you need to send SMS spam, use one of the "bulletproof" SMS spam players.

Even if we say customer is not a spammer, they are sending mail out to a wide variety of third party networks. In email land a closed SMTP server only forwards messages to an internal network or server under that admins control. As soon as you start blasting spam out to third party systems you are not a closed relay. That's literally how the verizon and other carrier systems will see this source of SMS spam and phishing.

The point about the reputation of IP or carrier / telephony origintion numbers / space remains. The use case here is prohibited by twilio's terms of service. Maybe just comply with those or find another provider.

An open relay is different from what you describe. My email account is not an open relay just because I can spam whomever I want from it, and neither is my twilio account.

And I don't need to send sms spam. If it was blocked on the way out, that'd be fine.

That's fine. Twilio is not targeting your use case then.

A lot of HN has turned into - X company MUST build me Y feature so I can do Z. Actually, if you read the docs, they provide clear guidance not to do Z (for whatever their reasons are). They have the same issues with reputation that someone running a mail server sending mail to users across multiple networks and third party email systems might have.

Maybe they should know they are employees? i.e. allow an employee to register their number and require inputting a texted code to confirm? (I don’t know if they do, not a customer.)

This does seem like a very common use case that Twilio needs to not punish.

No, they aren't designed for this use case. Sending messages from third parties is always MUCH higher risk then sending your own messages.

Same principal with money transfer. If you start accepting money from someone to transfer to another person that is MUCH MUCH higher risk - every bank / online payment player should be looking out for that and probably getting you into a different account type.

Twilio is clear, they are designed for systems where you message folks.

False. The customer may want to handle / filter the spam. The customer may be do a study of spam. The customer may be offering their customers a spam blocking service.

Fine to provide an option to filter it perhaps, requiring twilio to block what it THINKS is spam is a recipe for disaster, spam filters are no where near perfect.

> requiring twilio to block what it THINKS is spam is a recipe for disaster

Yet they are disabling the entire account when they think it has sent spam.

parent edited their comment.

At least in use cases I was dealing with - we wanted zero filtering of inbound SMS because it was used as a control interface.

Spam didn't matter to us. Spammers had no idea how to format their messages etc. We also whitelisted inbound numbers.

The Twilio use case is not primarily for "mailing lists" and third party sms forwarding stuff.

And for a while SMS worked very well in certain IoT's contexts (SMS used to basically have its own channel that had surprisingly good deliverability for some reason).

Internationally in particular voice and data used to be potentially wildly expensive.

For sat backhaul, you could get 10 to 25 cents a message. A voice minute would be like $5 - $10. So this is a 100x difference potentially. Even data minutes were like $1-5/minute way back. The connection setup and teardown times were lower with SMS then doing a voice channel call etc. Pricing looks a lot better now, but still, messages are cheap (or free).

https://www.satphonestore.com/airtime/iridium-airtime.html

How does twilio even know that you will only forward messages they have scanned for spam? It seems like they MUST put the spam filter on the outbound leg.

They could at least provide an indication when delivering the spam that "Twilio believes this message is spam and will block your account if you try to resend it".

provide an option? send spam to some other bucket that the customer can view? label it so customer can filter it? warn them / block outbound spam (if it's not high qps I dont see a reason for the zero tolerance here, some kind of restricted mode is more reasonable). Communicate with the customer, especially when they contact you..

So many other options here

It's really clear that folks don't

a) understand the market twilio is trying to serve

b) been in this market.

This guy probably is not checking is error codes. Twilio will always give you 30007 in these cases.

https://support.twilio.com/hc/en-us/articles/360008704834-Er...

Almost certainly this guy failed to follow their messaging guidelines. If you send (or forward) spam that includes links to third party websites or URL shorteners THEY TELL YOU that may trigger spam / blocking behavior.

And yes, this needs to be a zero tolerance game - with spammers the reasonable limits turn into 100 accounts being setup by folks in india for someone for 20 cents an account.

There's a whole contingent of engineers that are afraid of giving options to customers, and another that's annoyed at not having options. It's weirdly divisive and we're seeing that play out here.

My thought is that for any business-critical service, you need to have bought the service from person-to-person sales channels. Many boring meetings where they walk you through a slideshow of their service even though you already have it working. Many meetings worth of negotiating a price that's 10x the off-the-shelf price. All instead of, you know, making your product. It's just the cost of doing business -- $5/user/month if you're ok with them shutting you down because of a malfunctioning cron job, $30,000/year + meetings if you want someone's email that has to look into your problem. That's how software is these days, and unfortunately, literally everyone wants a piece. No task is too trivial to justify a 5 figure yearly cost, it seems. (Most recently, a well-known company tried to get that much out of me for hosting a static website!) There doesn't seem to be any market pressure to correct this problem, and I don't really understand why, but someone stands to make a lot of money if they crack the code. In the meantime, there's you and a problem, and giving the vendor your time and money can get the problem resolved. (Yup, you have to reward someone that's wronged you, because you already wrote code against their proprietary API. That's just how it is these days, and you have to accept it if you want to get anything done.)

I agree with the other comments that relaying phishing to internal users is probably what they dislike. There, of course, isn't a good solution beyond using some open platform. Your self-hosted IRC server isn't going to cancel your account because someone sent a phishing link, for example. But, nobody will know how to connect to it anyway. Sigh!

Makes total sense. If you buy a subscription for few dollars/month, don't expect a human being to answer your call. Google/Twillio/Sendgrid, whatever the service, all the same ticketing system and no real answer.

HN crowd looks down on sales reps. But a good sales rep will 1) understand your business 2) will look for ways to match your needs to solutions they offer 3) will be your point of contact when things go wrong.

Sales reps are human beings, treat them well, thank them for their time if you don't buy the fancy/expensive enterprise plan.They'll understand. Most reps are young college grads that are building a network for life.

You could be a solo SaaS creator and cheap because it is a side gig and your don't have the money. But still make an effort to nurture those little young reps. One day they'll make the phone call to somebody that will remove that account suspension. That will save your business.

I've dealt with several web hosting companies that had fully human operators respond very nicely when I had a problem even though my monthly hosting fees were tiny, rarely more than $20 per month. It's not impossible to offer a low cost service and still avoid being an unresponsive piece of shit to clients.

Yeah GoDaddy and HostGator are like this.

Amazon EC2 is not.

Also Google treats businesses like this if they have profiles on their maps. A business might rely on their google maps profile for 100k+ in revenue, but they can't get someone from google on the phone to help deal with it. I had someone steal my google maps listing from me and they got away with it because google would not connect with me about it. It was horrible and it was wrong.

> If you buy a subscription for few dollars/month, don't expect a human being to answer your call.

For a "few" dollars a month, maybe not.

But here the OP said it was around $600/month, so that's a fairly substantial chunk of ongoing spend, just to have zero way to contact someone on the phone on a showstopper problem that needs fixing ASAP.

Contrast with more traditional businesses like PG&E or Comcast. Both hated companies for reasons, but even so they are heads and shoulders above these cloud provider companies (google/twilio/etc) in terms of customer support.

I spend way less than $600 with each (around $100 for my small office) and yet I can immediately reach a human on the phone if there's any problem with my electric or internet service.

I kind of agree with this. I need to have that point-of-contact, so that if something blows up, they don't want to lose their commission, so they email the right person in the company to get it fixed.

The thing is, I actually had this when I first started with them. They were so small at the time, that I had one of the founders on the phone once and he told me all about how he studied cloud computing at MIT. But this was over 10 years ago. After that, they had phone support for a long time.

Last few years they changed over to this way where there is no path to resolving a problem like this, which should be easy to solve, in an appropriate amount of time.

Hey Chris, Greg from Twilio here. I'm so sorry for the frustration, lack of communication, and high friction to get this resolved. Want to drop me an email at gb@twilio.com and we'll see if we can get it sorted out?

Greg, it would be very useful if you could recommend a setup which would allow forwarding sms to employee numbers without the risk of account suspension.

Many of us use twilio and an account suspension is an undesirable scenario.

“Forward unless spam/problematic” would be very nice.

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.

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".

The fact that this particular customer was only able to get a "friendly" human resolution for this by first posting about his problem on a tech-heavy social media platform like HN speaks very poorly about your company's customer service. I know that the giants like Google, Facebook et al shit all over their users now that they're large, but it would be nice to believe that it hasn't turned into a fad even among smaller companies doing it against their fully paying clients. Shameful.

Even employees of those companies can't get help when they need it. I've seen a case where an employee's account was incorrectly banned (or well that was their assumption) and they still couldn't get through to any of the teams.

It's getting pretty rediculous

I read something about how Amazon was accidentally firing people in their warehouses due to an automated system. And the HR people in the warehouse didn't have the power to override it.

An offer to help is always appreciated.

But seriously, it can't take a thread on HN to get a way to get support for a paying customer. There needs to be an 800 number they can call which is staffed with humans empowered to fix problems.

While I have no connection to this thread, I am also using Twilio in production and finding out here that if we ever have a problem there will be nobody answering the phone makes me reconsider what we should be doing to keep our business uptime.

hopefully you can find a way to solve this. Sounds like all somebody needs to take a business offline is the knowledge that they are using twillo (easy) and that they're forwarding texts to employees.

Ok I just e-mailed you, thanks so much

When a company has gotten so automated that the only way to get a solution is to beg and plead for help about it on social media, it's too automated.

I agree.

Although this particular thing may have happened because they got backed into a corner by the carriers. They might have been forced to scramble and suspend a bunch of accounts in order to protect themselves from being suspended. It's possible this might not have been a gambit to save money, but something they were almost forced to do without time to properly prepare. I'm just speculating, guessing.

This is really frustrating, and sorry you're on the receiving end of this. I don't work for Twilio, but we spend a lot with them (and some other telecoms) so I see a bit further up the chain than most.

The retail wireless carriers are really driving a lot of this with recent 10DLC A2P changes. In particular, T-Mobile is waving around threats of $10k fines per message for messages they deem to be in violation of their content rules. (Which obviously prohibit fraud and such, but also somewhat-arbitrarily anything relating to marijuana.) The way it's written T-Mobile will fine Twilio, who is supposed to pass it on, but knows they'll struggle to collect that.

Meanwhile, on my personal cell phone AT&T can't even seem to figure out that when they get a message from a Nexmo number that starts with "ATT Free Msg" that they didn't send, maybe they shouldn't deliver it. As a consumer I'm glad someone is trying to squash these scams, but they're breaking more than a few eggs in the process.

I'd echo the advice to get off the SMS channel for notifications if at all possible, unless you're sending enough and spending enough to have named support contacts. The rules are being written for people sending thousands of messages per day. We serve small businesses who send maybe 100 messages per month, and it's been a mess trying to get carriers to recognize that these businesses exist and need a solution that works for them too.

Spam texts like that basically destroyed my phone number that I've had for 15 years :(

"You package (#US853121) containing the following products: 1. iPhone 13. Cannot be delivered until outstanding duties have been paid. Current outstanding balance: $1.68. More info <sketchiest website ever>"

I get about 20 of these a day. I've lodged multiple complaints. Like, why can't AT&T solve this problem that AOL solved in 1994?

I suspect you just have to pay for it and allow them to read and retain and aggregate your messages and use them for advertising.

UPDATE:::::

Due to Greg from Twilio seeing this post and providing me a way to reach out, I was able to get the problem resolved.

He spent about an hour on the phone with me today and provided some more information about the issue. A few highlights:

* Twilio has doubled in size since the beginning of the pandemic * Spamming and phishing through text message has gotten a lot more common very recently.

These two things together caused a sort of novel situation with them having to either auto-ban accounts of ban accounts with only a very shallow look and then not having a way for someone to get the account un-banned in a timely manner.

My initial concern with this post was that something had changed within the company culture where they were willing to cull off "smaller" accounts like mine in the $10,000 a year range by treating them very recklessly so that they only needed to work with very large companies which would be more simple and more profitable. This would mean that I would need to change providers or risk them doing other damaging things in the future that I would not be able to predict.

Based on a few things that Greg said in the conversation, I no longer believe this to be the case for a few reasons:

1) They have people like Greg reaching out to people like me at all. 2) In case Greg was not available the next time something like this happened, he provided me the contact information of some other people who were kind of high up in the company and explained that they would be very concerned that something like this was going on where legitimate customer accounts were being suspended.

This changed my interpretation of the situation because Greg's actions communicated to me that this is a temporary problem having to do with Twilio increasing in size very quickly at the same time spam and phishing became a big problem. They had to scramble to fix a problem with their providers before having a chance to refine their systems to make sure the implementation was done fairly and correctly. It does not seem to be a problem with top-level executives deciding that customers like me don't matter.

I also own a company and am very familiar with how things can get out of hand very quickly when demand increases. Shit hits the fan, then things suck for a while until the work is put in to become more organized. This takes time. And it takes trial and error.

I would expect over time for them to correct their systems and properly service smaller mid-range customers like me.

They only have people like Greg reaching out to you when your problem is posted on HN. They would have continued to ignore you had you not had the same reaction on HN. They've screwed up big time with us in the past and Greg wasn't reaching out.

What was the nature of the problem you had with them?

Mostly I can forget they exist and do other things with my business. But my use case is very vanilla: no outbound automated marketing, its used by only a few people at my specific company, we're not even a tech company -just blue collar stuff.

This year has been different though. I had to verify that I had a real business so that my number didn't get blocked on certain carriers, submitting the paperwork in the right way turned out to be kind of difficult, however I don't think this was something they had control over if I understand the situation correctly. One of the carriers blocked us anyway (They were blocking text messages with links to job info that I was sending to my employees). I used the ticketing system to get that problem fixed and they resolved it in a few days - I was under the impression it was kind of a complex problem too.

They also help us port numbers in from cell phones sometimes. And again the ticketing system is slow but they always get the problems resolved. None of these things being time sensitive, we were perfectly happy.

This type of thing is a difficult business problem for small and mid size businesses to solve. In this particular situation, I had a series of actions I was going to take to put out this particular fire. Normally I wouldn't do something like this, but my back was to the wall: * Call their sales number so I could plead my case to a real person within the company and have them put me in contact with someone * If that person refused - Call again and try with another sales person (This approach did not work because no one was answering the phone for sales, perhaps due to covid omicron?) * Post on HackerNews to see if I could get the attention of one of the brand ambassadors. (This worked, so I did not have to move on to the next steps) * Post on StackOverflow to see if I could get the attention of one of the brand ambassadors * Post on Reddit to see if I could get the attention of one of the brand ambassadors * Use LinkedIn to track down people who worked at Twilio. Use a paid service to get their phone numbers and addresses from their names. Call some of the people. * If no one answered the phone, go by the houses of Twilio employees who lived in my area

Long term, I wasn't sure what I would do because getting all the code switched to another provider would have been a huge hassle and it would have seriously gotten in the way of some of my other business development efforts. So I'm glad that Greg and Jeff reached out and reassured me that they don't intend to run their business this way.

A more difficult problem is Google and Facebook. I have had valuable pages stolen from me on both platforms (ex-employee) And neither company would engage with me. We're talking maybe $100,000 in lost property because of the amount of business the pages would bring in. Someone mentioned in another post on here that people are actually able to use HackerNews to get Google's attention. If I had known this I would have tried that. I knew Twilio might respond because they very often would help me when I posted technical questions on Stackoverflow in the past. I didn't think google and facebook cared as much about their brand because they have a monopoly.

You definitely did the right thing to get an urgent response. It's a shame you had to, but in your position I would do the same. Glad you've got it sorted, and it seems like you have some great suggestions in the thread to avoid this in future and have some contacts to help you out.

In my case, we sent over a ticket to port a number between accounts, and they ended up deleting our entire account, numbers, and all recordings and logs. They admitted it they made a mistake and processed the wrong ticket, but also flat out told us they couldn't recover anything. We were instructed to make a new account and they gave us our numbers back, but all our audio recordings, call logs, sms history etc was gone, all our SIDs, number ID's etc were different.

We have all screwed up, but we try to put things right. With Twilio it seems if they screw up, it's easier to leave you unhappy than do anything to fix it, unless you post on HN it seems.

Plivo is cheaper for phone numbers, free incoming SMS, and cheaper to send SMS.

Holy. Shit.

That would have been a freaking disaster if that happened to us, especially having to re-tool the application for new SIDs. I'm a little surprised that there is not a cooling off period after an account deletion as opposed to deleting everything immediately.

At least you got the numbers back.

Where I work, we use Pushover (https://pushover.net/) for this. A message comes in via SMS and then a handler stores it in a database then turns around, does some light filtering[0], and then sends a notification to a Pushover group. It's $5 per user per month for their teams feature, which we happily use.

0 - The handler doesn't send out via Pushover any message that contains words we're unlikely to use; Facebook is one, for example. If a message isn't forwarded via push notification, it is emailed to the sysadmin list for one of us to manually look at during daytime hours.

Oh very cool, thanks for this suggestion. I think the outgoing text messages actually add up to be kind of expensive too so this could save some money.

Wonder if it runs on Twilio..

I don't know what the SMS service part of Pushover uses as we don't send SMS through Pushover. The part we use, the main feature, sends a notification through an app the user installs on their device. All of us who receive push notifications through our system have the Pushover app on our phones, some also have it on their tablets and computers.

I like the Apple Watch integration as I can interact with urgent notifications just on my watch without my phone handy.

Interesting. I had an app, that had pretty much this functionality. Read the SMS from a phone and send a push notification with the content to a second phone. Google killed it though, because they said it does not have a legitimate reason to read SMS. Still a bit bitter about it.

You can rig this up yourself with Tasker and Pushover. There is an plug in for Tasker that enables using REST API calls and with variable names in the call so you can capture the text of an SMS. I used to do this for an old hotline phone.

Oh I didn't even realize they had SMS. I was just thinking I could use push messages instead of SMS.

Sorry you're going through this. At my last company we were in a similar spot to you - around ~$700/mo spending for Twilio. We had issues where they also were shutting us off and were unresponsive for days at a time. Once we had a rollout with a few dozen new clients in an area where we hadn't sent texts before and after sending a few thousand messages we were shut off at the carrier level. We tried reaching out for a day or two and really didn't get much back in response - to us this was the final straw and we moved to bandwidth.com (which I believe is who google uses for their auth).

Support with them is significantly better but if I remember correctly pricing is around $1k/mo minimum (which was more than worth it in our case).

Best of luck to you.

> I don't need tech support, I just need someone to call, explain the situation to, and have them click a button.

What you are describing is tech support.

>>What you are describing is tech support.

No that is customer support - big difference.

Why misdirect from the real issue just to rally an internet mob in your favor? The problem clearly isn't that you received a fraud text (as the title suggests), it is that you SENT fraud texts using Twilio. That will obviously get you banned from any mainstream service.

Also:

> I don't need tech support, I just need someone to call, explain the situation to, and have them click a button.

What do you think tech support is?

> Why misdirect from the real issue just to rally an internet mob in your favor?

Because what you described worked? They got customer service from two higher ups at Twilio who cared way more about the internet mob than literally everything else happening at their $42,000,000,000 company that is teetering on a confidence crisis based on share price trends, or the multiples that investors are willing to accept from this management team.

Hi Chris - CEO of Twilio here. I'm sorry for the issue. Fighting bad actors sucks, but we can do better to communicate with good faith builders like yourself. Mind sending me a note with your account at jeff@twilio.com, and I'll escalate for you.

A request from a random HNer – could you also commit to observing what the user's interactions with your customer service have been so far; and improving each of those, instead of nebulously "escalating" (where people will unblock an account because the CEO mandated it from up on high)?

Otherwise, you are contributing to a pattern where HN becomes de facto Tier 1 Customer Service, similar to how Twitter was a few years ago. This is already the case for various Google services [1], but I would hope that we don't want to normalize it for every service.

----------------------------------------

[1] A familiar pattern to most of us – Ask HN: Google suspended my account without warning; Googler escalates internally; problem is solved

I'm going to have to cop to this. I was desperate and needed a way to get my phone calls up and running. I have many employees that rely on me to feed their families. We employ a lot of refugees with large families and if I don't run my business right, they can't feed their families. This isn't a game.

I posted to HackerNews because I suspected my issue would be seen and taken seriously if I did that. I could tell the ticketing system people were overlooked and only looking at my issue in a very shallow way.

If this had not worked, I would have started using my Stack-overflow account then Reddit. If that didn't work, I found an address of a lady how works for Twilio nearby, I was going to go knock on her door and see if she could put me in touch with someone.

Luckily I was able to get the problem resolved without those additional steps.

I would like to point out that Twilio's ticketing system works well for complex problems that are not time-sensitive. I had an issue a few months back that I think was probably quite complicated involving bureaucracy and multiple carriers and it was resolved in a few days via their ticketing system which was very cool.

I totally understand your point of view, and you are not at fault at all. Anyone with a small business who's faced with the faceless, understaffed customer service at modern web companies would have done the same thing. I hope your issue gets resolved quickly.

IMO now that Twilio is a public company, they should be investing in better customer service. I am simply encouraging them to solve the actual problem in addition to unblocking you; hence the "also commit to...", not "instead commit to..."

I hope my comment is not used as justification to not solve your problem. That would be the very last thing I want.

Oh no, I didn't take it that way. I just thought what you said was very interesting and wanted to provide more information and confirm that you were correct.

Hey Jeff,

Thanks for taking the time to respond. The fact that you responded to this message at all resolves my initial concern, which had more to do with if I needed to change providers because of a cultural shift within your company. I understand that you are dealing with a very large and complex system that is changing quickly and will have problems, sometimes serious problems sometimes. Customer communication specifically is a very difficult and complex problem to solve at scale.

I actually spoke with one of the founders of Twilio when I first signed up. Evan maybe? He told me about how he studied cloud computing at MIT. This was a very long time ago.

Gregg was able to get the problem resolved within about 30 minutes once I reached out to him. He also provided me with a few solutions to prevent the problem in the future.

I understand the complicated problem that that led to this mistake and I think it is reasonable to make mistakes like this sometimes, especially if you're providers are threatening to suspend you.

The main problem that I would like you to solve is the lack of phone number. There needs to be a way for people to contact the company if there is an account administration emergency like this. Even chat would have been fine.

That being said, I did call sales and could not reach someone. If this is due to covid omicron and if normally I had called sales and would have been able to plead my case and gotten them to connect me with someone, I think that would have been fine and this truly is an edge case.

Not excusing their lack of support, but at the end of the day you sent a spam/phishing message through their service. What exactly are they supposed to do? If they don't immediately shut down accounts that send these messages, they're going to be in hot water with the cellular carriers. It's by far the lesser of two evils to just shut down accounts that send spam.

No, someone else sent a spam message into Twilio's system, and, rather than dropping it on the floor, Twilio's system then forwarded the spam on to their customer's list, then blamed the customer for it.

Nope, that's not how Twilio works. Yes, someone else sent a spam message, but Twilio did not forward it to "their customer's list" whatever that means. Twilio forwarded it to their customer's application, which was the end of the line for Twilio. At that point, their customer's application sent out that spam message to whoever was configured to receive it. As far as Twilio is concerned, the incoming and outgoing messages have no relation.

That's a distinction without a difference.

By their own policy, Twilio's upstream should ban them for "forwarding spam".

I'm guessing they would not be happy if that policy were applied.

You are really good at explaining these things.

Very often people say things that I know are incorrect and actually sound quite stupid, but then I am unable to articulate why. I was very surprised at the number of incorrect negative responses from people to this post, who seemed to grab onto details and then use them to twist reality.

How did you learn to dissect these arguments and then clearly refute them?

Also, I have never heard "distinction without difference" before, but it is a common way that people twist reality. Did you study logical fallacies? Or read a good book on how to deal with them?

Did your application not send out the spam texts? What are you even saying?

We were paying them around $1500/mo and had a similar issue where they blocked some (in our case) legitimate messaging traffic. We switched most of our traffic to another provider and are pleased. We had been a Twilio customer since 3 days after they launched and I owned a significant amount of their stock. I sold it all when this happened in spring of last year and I'm glad I did... stock has gone down significantly since. I don't see Twilio doing well long term, they provide an API for a network they don't own.

Which provider did you end up using?

Pinged you direct with more info

It's been a year or two since Twilio became so large that the left hand has no idea what the right hand is doing. You have my sympathies. Good luck.

They were also a nightmare for us. We had to find another provider.

Could you recommand one that provies SIP trunking and number porting?

Check with Sinch and Infobip.

Unfortunately no.

For an alternative, maybe relay the texts to a slack channel (that's easy enough to receive on a phone for your coworkers). Zapier can probably integrate twilio/slack quickly.

Yes, I will do something like this. However it doesn't alleviate the overarching concern that they are behaving in a way that treats my business very recklessly.

I use Slack like this for various notifications. I just setup a new Slack instance and created channels for each notification area (smart home, media server, etc). Now all the software in those various areas can send messages (via webhook) and I can set the alert preferences per channel. Makes it easy to quickly look at Slack and know things are running fine.

I also have a #critical channel anything can post to that always has alerts enabled on my phone so I don't miss anything important.

It actually works pretty well and costs nothing.

Then what do you do when Slack bans your account?

Self-host Zulip - which in my opinion is better than Slack anyway and supports slack incoming webhooks.

https://zulip.com/

I'm going to guess that slack would not ban for this reason. It would not make sense at all.

Twilio deleted our account, phone numbers and thousands of audio recordings after we sent them a request to port a single number to a different account. Support admitted it was a mistake on their end but insisted there was nothing they could do except have us open a new account, and they could try and restore any unreleased numbers back.

All data was lost, number ID's, account ID's all completely different. It took us a LOT of dev hours to update everything, whilst losing some of our customers. Twilio is cheap, fun and dev friendly until they mess up, then you're on your own.

No experience with Twilio, but yours makes me glad that's not the case.

As another small biz, I've had very good experience with Phone.com over the past several years. Prompt and solid tech support the few times I need it (mostly for configuration and 'is there a way to do this peculiar thing?' questions), and mostly just works.

The only real solution for this is going to be the government stepping in and ordered the carriers to fix their fraud and abuse issues.

They're trying to offload the problem onto Twilio which then winds up passing that onto their customers.

Of course solving the abuse problem means spending money to cut off the revenue they actually see from the scammers sending texts. They'll never be incentivized to do anything about it unless the government were to make them an offer that they couldn't refuse.

That'll never happen though because the government is bought off by corporate lobbyists, so we will continue to evolve into more and more of a third world scam economy.

Suggestion to Twilio, if you're reading: if you have the ability to detect spam messages, perhaps give your users an API call for filterSpamAndSend instead of just send.

The carrier (ATT, Verizon, etc) probably flagged this as spam - not Twilio.

I am confused by one thing - when you forward to your employee's phone number is that number also owned by your company? Or is it a phone number owned by the employee.

If the first Twilio should fix this bug in their system, if the second then they should maybe have some process of setting up employee phone numbers in their system so the shut down process does not happen. At any rate both scenarios should be common enough that they should have a process to handle that.

I'd look at SignalWire. It's way cheaper than Twilio and they use the same APIs.

For couple of years we moved from Twilio to Pilvo and trust me it works great and it is cost-effective as well.

I need the message to pop up on his cell phone just in case he is not at the computer.

Slack is probably a good idea.

Of course we have an internal database and he can look at text messages through our web application too. But these are not push notifications to his phone.

Auto-banning an account is a violation of GDPR Article 22

https://gdpr-info.eu/art-22-gdpr/

> The data subject shall have the right not to be subject to a decision based solely on automated processing, including profiling, which produces legal effects concerning him or her or similarly significantly affects him or her.

Quote this and maybe it will get you escalated, but who knows? A lot of companies seem to just ignore GDPR entirely.

Paragraph 1 shall not apply if the decision: is necessary for entering into, or performance of, a contract between the data subject and a data controller; is authorised by Union or Member State law to which the controller is subject and which also lays down suitable measures to safeguard the data subject’s rights and freedoms and legitimate interests; or is based on the data subject’s explicit consent.

If you send abusive texts through Twilio, Twilio could lose it's contracts with carriers. I haven't read through the paperwork Twilio makes you sign, but I'm gonna guess the fact that this could happen is in there. Also it sounds like the account wasn't banned, it's ability to send messages was suspended. Because it was being used to send spam text messages. I'm pretty thankful Twilio has automated systems for that

This is absolutely not applicable even if both parties were in the EU, a company can not be a data subject under GDPR (only "natural persons" are), any GDPR clauses about automated decisions (and others) protect only individuals and not B2B accounts.

GDPR can only be enforced for citizens in the EU/EEA and (for now) the UK. I think the OP is based in the US as is Twilio.

Thats right, we're in the US

Nitpick: The GDPR says it applies to persons who are "in the Union", which seems it would cover non-citizens who reside in (or are even just visiting) the EU, and would not cover EU citizens who are not in the Union.

Yeah, re-reading I should have used "persons" rather than "citizens"; was playing a fast and loose with the meaning of "citizen" and didn't actually mean a "citizen of".

Seems like it’s his fault. I’m currently using the twilio API. A simple Python script could be used to filter out any messages that weren’t sent from an employee. He essentially has an unauthenticated open relay, a one way ticket to get put on a spam blacklist in the SMTP world.

Except that "open relay" is to very specific numbers, not to just any # . I would like to think there must be a way to send whatever to authenticated / opted in numbers?

DISCLAIMER: I do work for TWLO, but on a completely unrelated division. My opinion and this message does not represent my employer in anyway. I'm just shooting the breeze here.

It's not an unauthenticated open relay.

It's like if you had a restaurant and you wanted to use Twilio. You might forward text messages sent to the restaurant number hosted on Twilio to your personal cell phone number.

Exactly, it's just call forwarding but for messages instead of voice calls. Completely legitimate business use case.

> I should be considering bearing in mind that it would be expensive to re-write the software to work with another vendor

Well, maybe next time you get somebody that implements a standard.

With that kind of behavior (not letting you speak to anybody, the blocking is understandable), it's clear you shouldn't keep their services. So, you have now an opportunity to do it right, and make the next move cheaper.

There isn't a standard for these apis though

VoIP is entirely based on SIP, everywhere. Those providers just add a proprietary API over it. But if the use case is just sending texts, that one may evade the standard (I don't remember it entirely, and it certainly evolved since last I used it).

But then, if they were only sending texts, migrating wouldn't be expensive.

It sounds like you relayed a message that contained abusive content. To twilio it looked like your account was sending abusive content and they acted according to agreements with carriers to prevent abuse. Don't relay abusive content and you won't have this problem.