It seems to effectively be forwarding the text messages, like an SMS mailing list. If Twilio can't deal with forwarding messages as they come in, no matter the content, it's their problem.
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.
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
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.
If Twilio can detect that it's spam, surely the correct procedure would be to block it when it first comes into Twilio's system from outside, not blindly forwarding it to a customer's list and then blaming the customer for it!
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.
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.
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).
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..
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.
