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".
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.
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 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
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.
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.
And I don't need to send sms spam. If it was blocked on the way out, that'd be fine.
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.
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"
Spam detection is not perfect. Users may want to process their own messages unmolested inbound.
This does seem like a very common use case that Twilio needs to not punish.
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.
Sorry, this is just bad design.
Re: > The customer may want to handle / filter the spam.
Then provide the customer with a "yes, send me all the spam" option.
Which do you suppose is the common case here?
1) Customer doesn't want spam.
2) Customer is doing a "study of spam"
3) Customer is running a spam filtering service.
Yeah, it's 1), dude, in a gigantic majority of the cases.
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.
Yet they are disabling the entire account when they think it has sent spam.
So many other options here
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.
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.