3 ms·

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

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

by rsync 5y ago

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.