5 ms·

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

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.

onphonenow 5y ago
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".
- boardwaalk 5y ago
  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.
  - onphonenow 5y ago
    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.
- Xylakant 5y ago
  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.
  - onphonenow 5y ago
    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.
    - jjnoakes 5y ago
      > 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.
      - onphonenow 5y ago
        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
  - ihumanable 5y ago
    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"
    - Xylakant 5y ago
      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.
      - onphonenow 5y ago
        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.
- Turing_Machine 5y ago
  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.
  - onphonenow 5y ago
    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.
    - jeremyjh 5y ago
      > 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.
    - deleted 5y ago
      [deleted]
    - cjm42 5y ago
      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".
    - desmosxxx 5y ago
      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 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.

onphonenow 5y ago

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

boardwaalk 5y ago
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.
- onphonenow 5y ago
  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.
Xylakant 5y ago
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.
- onphonenow 5y ago
  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.
  - jjnoakes 5y ago
    > 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.
    - onphonenow 5y ago
      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
- ihumanable 5y ago
  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"
  - Xylakant 5y ago
    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.
    - onphonenow 5y ago
      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.
Turing_Machine 5y ago
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.
- onphonenow 5y ago
  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.
  - jeremyjh 5y ago
    > 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.
  - deleted 5y ago
    [deleted]
  - cjm42 5y ago
    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".
  - desmosxxx 5y ago
    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