Send SMS [in the US] using python (Without Twilio)
;)
I think these kind of SMTP to SMS gateways are common in North America but, for example, I don’t think any Australian mobile carriers offer them. Unsure about how common they are in the rest of the world, but wikipedia only mentions US & Canada.
Believe the reason they don’t exist in countries like Australia is that subscribers have never paid to receive SMS here (sender pays). So there’s never been an incentive for a carrier to offer such a thing.
Thanks for the clarification. After reading the short text I was left with the question how the payment would be performed (if the mobile number would not be somehow tied to the SMTP login before-hand). From the other perspective: Isn’t a receiver pays scheme together with these SMTP gateways the perfect way to get DOS’ed (in regards of money). Someone just has to send thousands of SMS to you and at some point either your prepaid money will be empty or you will have a very huge invoice.
In Europe I have used smstools for sending SMS with a USB-SIM-Card adapter. This comes with a daemon that monitors a folder for text files. When a new text file arrives, it will process it and send it out. So from Python it’s then simple enough to send out an SMS by writing a text file.
Isn’t a receiver pays scheme together with these SMTP gateways the perfect way to get DOS’ed (in regards of money). Someone just has to send thousands of SMS to you and at some point either your prepaid money will be empty or you will have a very huge invoice.
I also wondered how this part works, maybe some Americans who know about a bit about the telco industry can explain?
(I’m also not sure if any US carriers still charge to receive SMS, I just know that they used to - I think now it’s usually a bundled free addon.)
American here. You’re correct in that most US carriers no long charge for text messages, but rather lump it in with monthly bandwidth limits. When carriers did charge for texts, it was back in the pre-smartphone era, and still fairly new, and I wasn’t aware of any large scale DDOSing. However, it was always flawed, in that your friend could text you a bunch a you’d get charged a lot. I remember a lot of telling people to stop texting or shutting off my phone near the end of the month.
I quickly researched and it seems that in Austria (not Australia) a similar (but different) email to SMS gateway also exists - e.g. in the email Business Package from A1. It’s charged per SMS sent.
There is no documentation, but to my understanding you basically login to your A1 e-mail account normally and then send an e-mail to [number]@smssenden.at. They will then detect “aha, this e-mail actually is an SMS” and re-route it for you. So unlike in the US way explained in the article you always use smssenden.at as destination and A1 will handle whatever carrier the recipient has.
From Malaysia. Back in early 2000, this is trick we use to send sms for free. But these days I don’t think any of the local carrier has that email address open anymore.
You usually don’t need to pay for SMS these days, it’s included as a free add-on from most carriers (at least in Australia and most countries I’ve ever visited).
The point is that in the US you used to have to pay to send and receive SMS, but in some other countries you only ever had to pay to send. And my understanding is that these SMTP carrier gateways exist from this time. Less clear that the carriers would have an incentive to add them now, if they didn’t already exist (harder to take something away after customers have been relying on it for almost two decades).
I think this method should be avoided if at all possible. It’s a great solution if you’re just writing a script for personal use and you want to receive a text when something happens. But for production applications, this should NOT be used.
If your users aren’t using a big-name carrier (like me) they won’t be able to receive the SMS since there is no email gateway for them. At least, there might be an email gateway, but whenever I see any web application with SMS configuration and it asks for your carrier in a dropdown, I know they’re using this method and, unsurprisingly, my carrier isn’t listed, ever…
So this should not be used for anything like 2FA or a notification that can only be received by SMS.
We used this method at work for our on-call notification system. We created contact cards on O365 with the SMS gateway number of the on-call phone (or personal numbers if you didn’t want to carry around another phone) and added them to a distribution list that was emailed whenever things went wrong. It was surprisingly simple and robust.
I just tried it and it works in the Netherlands as well, if you send an SMS enabling the email gateway to your phone company. (I followed this to find the SMS and number to send to.)
I just skimmed through, but … is it just me or there’s no authentication? Does it mean I can spam like hell just by putting the script in a while loop? This seems odd.
Actually I have tried that on my friends and number only gets blocked if they choose otherwise you can send more than 500 since daily sending limit of gmail is 500 emails
I also thought so at first, but after re-reading there is an SMTP login. I’m currently under the impression that I might have misunderstood the article. At first I thought you have to check the recipient’s carrier and use the correct gateway for each recipient.
Now I think that you have to use the gateway of your own carrier and your carrier will forward it within the SMS network. At least this seems to be how it works in Austria (but there was not too much information during a quick research either). Since mobile phone numbers are unique this should work. If you are a customer of example.com and your recipient is a customer of example.net, you basically send a mail to 12345@smsgateway.example.com and example.com gateway will know “aha, this is an SMS from our dear customer A, that should go to 12345. 12345 is part of carrier example.net, so we will send it there. Now we will charge customer A 10 cents for the SMS”.
But this requires that you do not only have SMS with that carrier, but also an email account (or at least an email account with the gateway). Which is true for the case I researched in Austria. In fact it seems you only need an email account with that provider and do not need to have an SMS account at all.
Update
Ok, no, you are right. The login in the article indeed goes against smtp.gmail.com.
In this case, the US system is different from the system I found in Austria (where the mail gateway basically is a service provided by the telco company to business customers and they will then handle SMS submission).
A long time ago when I had a flip phone and no data plan, I used procmail and a little script to send myself new e-mail notifications via sms by using an sms gateway. It was often useless because it was hard to fit sender, subject and enough body to be useful into the sms without going over the sms character limit.
This is very cool, I am not sure what underlying technology Twillio is using, but if they are also using the gateway model, I wonder how they figure out which provider a given number is on.
;)
I think these kind of SMTP to SMS gateways are common in North America but, for example, I don’t think any Australian mobile carriers offer them. Unsure about how common they are in the rest of the world, but wikipedia only mentions US & Canada.
Believe the reason they don’t exist in countries like Australia is that subscribers have never paid to receive SMS here (sender pays). So there’s never been an incentive for a carrier to offer such a thing.
Thanks for the clarification. After reading the short text I was left with the question how the payment would be performed (if the mobile number would not be somehow tied to the SMTP login before-hand). From the other perspective: Isn’t a receiver pays scheme together with these SMTP gateways the perfect way to get DOS’ed (in regards of money). Someone just has to send thousands of SMS to you and at some point either your prepaid money will be empty or you will have a very huge invoice.
In Europe I have used
smstoolsfor sending SMS with a USB-SIM-Card adapter. This comes with a daemon that monitors a folder for text files. When a new text file arrives, it will process it and send it out. So from Python it’s then simple enough to send out an SMS by writing a text file.I also wondered how this part works, maybe some Americans who know about a bit about the telco industry can explain?
(I’m also not sure if any US carriers still charge to receive SMS, I just know that they used to - I think now it’s usually a bundled free addon.)
American here. You’re correct in that most US carriers no long charge for text messages, but rather lump it in with monthly bandwidth limits. When carriers did charge for texts, it was back in the pre-smartphone era, and still fairly new, and I wasn’t aware of any large scale DDOSing. However, it was always flawed, in that your friend could text you a bunch a you’d get charged a lot. I remember a lot of telling people to stop texting or shutting off my phone near the end of the month.
I quickly researched and it seems that in Austria (not Australia) a similar (but different) email to SMS gateway also exists - e.g. in the email Business Package from A1. It’s charged per SMS sent.
There is no documentation, but to my understanding you basically login to your A1 e-mail account normally and then send an e-mail to [number]@smssenden.at. They will then detect “aha, this e-mail actually is an SMS” and re-route it for you. So unlike in the US way explained in the article you always use smssenden.at as destination and A1 will handle whatever carrier the recipient has.
From Malaysia. Back in early 2000, this is trick we use to send sms for free. But these days I don’t think any of the local carrier has that email address open anymore.
I am surprised I didn’t know you had to pay for sms outside US
You usually don’t need to pay for SMS these days, it’s included as a free add-on from most carriers (at least in Australia and most countries I’ve ever visited).
The point is that in the US you used to have to pay to send and receive SMS, but in some other countries you only ever had to pay to send. And my understanding is that these SMTP carrier gateways exist from this time. Less clear that the carriers would have an incentive to add them now, if they didn’t already exist (harder to take something away after customers have been relying on it for almost two decades).
I think this method should be avoided if at all possible. It’s a great solution if you’re just writing a script for personal use and you want to receive a text when something happens. But for production applications, this should NOT be used.
If your users aren’t using a big-name carrier (like me) they won’t be able to receive the SMS since there is no email gateway for them. At least, there might be an email gateway, but whenever I see any web application with SMS configuration and it asks for your carrier in a dropdown, I know they’re using this method and, unsurprisingly, my carrier isn’t listed, ever…
So this should not be used for anything like 2FA or a notification that can only be received by SMS.
I see I wasn’t really sure that you have to pay for sms outside the US
We used this method at work for our on-call notification system. We created contact cards on O365 with the SMS gateway number of the on-call phone (or personal numbers if you didn’t want to carry around another phone) and added them to a distribution list that was emailed whenever things went wrong. It was surprisingly simple and robust.
Nice I see
I just tried it and it works in the Netherlands as well, if you send an SMS enabling the email gateway to your phone company. (I followed this to find the SMS and number to send to.)
I just skimmed through, but … is it just me or there’s no authentication? Does it mean I can spam like hell just by putting the script in a while loop? This seems odd.
They’ll blacklist where you are sending it from pretty quickly if you spam. Each individual carrier controls those things (in the US at least)
Actually I have tried that on my friends and number only gets blocked if they choose otherwise you can send more than 500 since daily sending limit of gmail is 500 emails
I also thought so at first, but after re-reading there is an SMTP login. I’m currently under the impression that I might have misunderstood the article. At first I thought you have to check the recipient’s carrier and use the correct gateway for each recipient.
Now I think that you have to use the gateway of your own carrier and your carrier will forward it within the SMS network. At least this seems to be how it works in Austria (but there was not too much information during a quick research either). Since mobile phone numbers are unique this should work. If you are a customer of example.com and your recipient is a customer of example.net, you basically send a mail to 12345@smsgateway.example.com and example.com gateway will know “aha, this is an SMS from our dear customer A, that should go to 12345. 12345 is part of carrier example.net, so we will send it there. Now we will charge customer A 10 cents for the SMS”.
But this requires that you do not only have SMS with that carrier, but also an email account (or at least an email account with the gateway). Which is true for the case I researched in Austria. In fact it seems you only need an email account with that provider and do not need to have an SMS account at all.
Update
Ok, no, you are right. The login in the article indeed goes against smtp.gmail.com. In this case, the US system is different from the system I found in Austria (where the mail gateway basically is a service provided by the telco company to business customers and they will then handle SMS submission).
A long time ago when I had a flip phone and no data plan, I used procmail and a little script to send myself new e-mail notifications via sms by using an sms gateway. It was often useless because it was hard to fit sender, subject and enough body to be useful into the sms without going over the sms character limit.
Wow thats interesting. To be honest I made this for fun or sometimes if i want to send something to my phone i can just simply use the terminal
This is very cool, I am not sure what underlying technology Twillio is using, but if they are also using the gateway model, I wonder how they figure out which provider a given number is on.
Suspect Twilio either acts as a carrier, or uses some mix of the other SMS-oriented protocols that carriers and ESMEs use to relay messages:
Thank you for these links, its an interesting world that I’ve never really considered.
I think there’s an api that can recognize your provider but you have to pay for the Api