1

I've been using AWS SNS to send SMS short codes, which I have been able to do successfully (The short code I receive AWS SMS messages from is 37083). However, I noticed that if I respond to any of these messages, I get spam back.

AWS SNS does not provide two way communication, but if I respond to the short code 37083 "STOP" I receive spam back. I received the following message:

You are unsubscribed from alerts. No more messages will be sent. Reply HELP for help, email help@smshelps.com or 1-xxx-xxx-xxxx.

This seemed odd, so I replied "HELP" and got the folloiwng message back:

For Daily Job Match Alerts: Help email Support@smshelps.com or 1-xxx-xxx-xxxx. Msg and data rates may apply. text STOP to cancel. 3 msgs/week****

If AWS doesn't support two way communication, who/which provider is responding and why are we getting this spam?

I understand that we are using a shared short code, but aren't the pooled AWS short codes only shared by AWS users? Clearly this one seems to becoming from a different provider.

I dug a bit deeper and found that the short code 37083 is leased to amazon and no one else. I also found a list of Amazon Short codes. I tried sending "HELP" to some of the other Amazon short codes and did receive messages back, such as following message when I sent "HELP" to 58988 (58988 is a shared short code leased by Amazon)

Where is my Truck. Delivery alerts. Recurring messages...

Is there some other provider that is also leasing the same short code? My understanding was that only one provider leases a short code at a time. That provider then managers that shared short code and shares it with users.

Eric
  • 2,008
  • 3
  • 18
  • 31
  • Have you tested this on phones from multiple independent carriers? One phone carrier had an episode of rampant technical incompetence several years ago that routinely prevented their customers from calling anyone who switched their service from one carrier to another even though neither old nor new carrier of the person who couldn't be called was actually the company in question... and this *might* be an example of something similar. – Michael - sqlbot Jun 01 '17 at 06:34
  • @Michael-sqlbot yes I tried AT&T and Verison. Received the same message back on both. – Eric Jun 01 '17 at 20:14
  • Wow. I tried it on Sprint, same result. That seems distinctly wrong. Further, using 2 *entirely* unrelated AWS accounts, they both send me messages from 58988. The "STOP" reply seems to opt-out whichever one messaged me last. Theory: AWS is the assignee of the code, but what if it's actually being gatewayed through a 3rd party vendor? (e.g. a company that imagines itself to be another Twilio doesn't operate at the same excellent standard as Twilio). This third party has issues, and delivers the `STOP` replies back to SNS but also returns the incorrect response. Theory. Still looking... – Michael - sqlbot Jun 01 '17 at 21:15
  • @Michael-sqlbot I tried with 2 different accounts and got messages from different short codes (37083 and 44154) both which return the same "Daily Job Match" message. Apparently, it is required that a response is given when certain words such as STOP or HELP are sent. It might be possible that Amazon has not configured this (as it doesn't support two way comms) and instead uses the messages that were sent by the previous leaser of the short codes. Though, I would expect for AWS to have some default response... (https://www.usshortcodes.com/info/static/docs/Monitoring_Handbook.pdf) – Eric Jun 01 '17 at 23:45
  • In regards to the "STOP" being sent. I found that it opts you out of messages from that short code completely. However, your AWS account only knows about the phone number being opted out if you sent a message from that account. – Eric Jun 01 '17 at 23:45
  • For example, I have two AWS accounts, lets call them AWS_1 and AWS_2. If I send a message from AWS_1 to my phone number 555-1234 and then reply "STOP." AWS_1 now shows 555-1234 as being opted out and it cannot text the number. However, AWS_2 does not show 555-1234 as an opted out number, but it CAN'T send text messages to it either. Also, AWS_1 can opt 555-1234 back in, however, AWS_2 CAN'T opt 555-1234 back in. So essentially, AWS_2 can never text 555-1234 again as it doesn't know that it is opted out and can't opt back in. – Eric Jun 01 '17 at 23:46
  • This seems like it *has* to be a misconfiguration in a routing database somewhere external to SNS, but I am not an authority on how SMS routing works... however, from my days as a telephone engineer, a problem of this nature sadly does not surprise me. But... none of this seems characteristic of AWS, so suspect the issue is at least partially external to them, but they'll be the ones who'll need to identify it and force a fix for it. Found this on the forum, too: https://forums.aws.amazon.com/thread.jspa?messageID=787235. Added a link back to here. – Michael - sqlbot Jun 02 '17 at 00:36
  • 2
    I'm not affiliated with AWS, but while chasing this down, I found myself in contact with someone who turned out to be the senior product manager for SMS at AWS. They are now aware of the issue. I'll update if I learn more. – Michael - sqlbot Jun 02 '17 at 20:47

1 Answers1

3

There are no providers using the same short code and it wasn't spam.

The US and Canada require that short codes must accept STOP/HELP messages for end-users to opt-out from receiving any further messages, and to receive more information, respectively. That was the default message replied from any short code that didn't request a specific message for these HELP/STOP keywords.

The message replied to these keywords has been replaced with a generic one.

2-way communication is not supported yet.

Source (disclosure): I work in that team.

pnv
  • 231
  • 1
  • 6
  • 1
    Thanks for the help! I understand the requirements in US and Canada, but why is the default message replied to those keywords "For Daily Job Match Alerts: Help email Support@smshelps.com...". The linked phone number is associated with spam (doing a google search), the URL doesn't work, and my customers don't care about Daily Job Match Alerts. It seems like a pretty inappropriate reply for AWS to use as a default for one of their short codes, wouldn't you say? Anyways, I did check again and 37083 returns a "To stop last sender from sending you messages please reply STOP." Much better! Thanks! – Eric Jun 05 '17 at 14:02
  • 2
    Thanks to you, Eric. We appreciate the feedback. – pnv Jun 05 '17 at 18:10
  • I would have hoped to see the phrases "misconfiguration" and "upstream provider" in the answer. :) It defies logic that SNS itself was deliberately sending this response by default, and I doubt that was the case, but the answer leaves it ambiguous where the responses were coming from. – Michael - sqlbot Jun 05 '17 at 18:15
  • @Michael-sqlbot we were sending this response from our service. When we transitioned to specific responses per HELP/STOP keyword, this message was kept. We appreciate the feedback and understand how this might've affected customer experience. – pnv Jun 05 '17 at 19:26
  • @pnv That was my theory after I dug a bit deeper into this. Again, thanks for the help! – Eric Jun 05 '17 at 23:14