12 ms·

> 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

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

ghusbands 5y ago
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.
- ChrisDutrow 5y ago
  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.
vorpalhex 5y ago
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.
- ChrisDutrow 5y ago
  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.
  - nikanj 5y ago
    Rules for thee, not for me
  - Fatnino 5y ago
    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.
    - ChrisDutrow 5y ago
      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.
- jdavis703 5y ago
  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.
  - ChrisDutrow 5y ago
    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.
  - foota 5y ago
    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.
    - Nexxxeh 5y ago
      It was only spam on the inbound leg. On the outbound leg, it was requested and correct content.
- madars 5y ago
  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] 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
  - ChrisDutrow 5y ago
    Yes, these are very good ideas. Didn't even think of the JPEG one, very cool!
    - flippy_flops 5y ago
      At a high enough volume, links will also get you blocked by carriers
    - secabeen 5y ago
      Yeah, we pass all of our twilio messages to our staff via a special Slack channel.
      - ChrisDutrow 5y ago
        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
        throwaway220107 5y ago
        secabeen 5y ago
        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).
ChrisDutrow 5y ago
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.
- YXNjaGVyZWdlbgo 5y ago
  The fact is that you are sending spam over twilios network even if it's just to your own employees. You are also saying it is not the first time it happens and you seem to have done noting to mitigate the problem at hand furthermore is it an attack vector for phishing against your company. The fact that you are not ingesting the text into another system is also a bit concerning how do you handle GDPR requests? If you are looking at the problem objectively twilio is in the right.
  - Turing_Machine 5y ago
    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.
    - YXNjaGVyZWdlbgo 5y ago
      You are suggesting that a service that has no idea of what your business is should curate your data and "simply drop it"? yikes.
      - ejb999 5y ago
        >>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?
kamray23 5y ago
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.
tobyjsullivan 5y ago
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.
- willcipriano 5y ago
  As a text message recipient, I can't say I'm mad about Twillo's choice here.
  - ChrisDutrow 5y ago
    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.
  - exsmelliarmus 5y ago
    I’m assuming you would be if your business was harmed through an honest mistake.
    - willcipriano 5y ago
      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.
rsync 5y ago
"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.
- fatnoah 5y ago
  "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.
- fatnoah 5y ago
  >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.

ghusbands 5y ago

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.

ChrisDutrow 5y ago
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.

vorpalhex 5y ago

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.

ChrisDutrow 5y ago
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.
- nikanj 5y ago
  Rules for thee, not for me
- Fatnino 5y ago
  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.
  - ChrisDutrow 5y ago
    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.
jdavis703 5y ago
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.
- ChrisDutrow 5y ago
  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.
- foota 5y ago
  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.
  - Nexxxeh 5y ago
    It was only spam on the inbound leg. On the outbound leg, it was requested and correct content.
madars 5y ago
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] 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
- ChrisDutrow 5y ago
  Yes, these are very good ideas. Didn't even think of the JPEG one, very cool!
  - flippy_flops 5y ago
    At a high enough volume, links will also get you blocked by carriers
  - secabeen 5y ago
    Yeah, we pass all of our twilio messages to our staff via a special Slack channel.
    - ChrisDutrow 5y ago
      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
      - throwaway220107 5y ago
      - secabeen 5y ago
        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).

ChrisDutrow 5y ago

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.

YXNjaGVyZWdlbgo 5y ago
The fact is that you are sending spam over twilios network even if it's just to your own employees. You are also saying it is not the first time it happens and you seem to have done noting to mitigate the problem at hand furthermore is it an attack vector for phishing against your company. The fact that you are not ingesting the text into another system is also a bit concerning how do you handle GDPR requests? If you are looking at the problem objectively twilio is in the right.
- Turing_Machine 5y ago
  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.
  - YXNjaGVyZWdlbgo 5y ago
    You are suggesting that a service that has no idea of what your business is should curate your data and "simply drop it"? yikes.
    - ejb999 5y ago
      >>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?

kamray23 5y ago

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.

tobyjsullivan 5y ago

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.

willcipriano 5y ago
As a text message recipient, I can't say I'm mad about Twillo's choice here.
- ChrisDutrow 5y ago
  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.
- exsmelliarmus 5y ago
  I’m assuming you would be if your business was harmed through an honest mistake.
  - willcipriano 5y ago
    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.

rsync 5y ago

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

fatnoah 5y ago
"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.
fatnoah 5y ago
>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.