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.