Send text messages for free using Python | Hacker News Reader

Send text messages for free using Python

alfredosequeida.com

In 2009, I could send and receive text messages though SMS gateways that would control my arduino-controlled hot tub that my friends and I got for $100 on Craigslist. I could adjust the temperature and it would acknowledge and tell me when the programmed temperature would be reached based on the time derivative. This was useful as a grad student in Ann Arbor winters.

I had a python script running on a handmedown computer running Ubuntu 8.10 that just periodically checked an email account, parsed the command, flipped the relay as necessary, read the temperature rise, and replied.

Writeup: https://partofthething.com/thoughts/hot-tub-controller/

For a second I thought you were one of my roommates, because we had a very similar setup for our (free) hot tub. Ours was a few years earlier and using older hardware.

We had an actual server in the garage, with a X10 firecracker on one serial port and a temperature sensor on the other. We used a 220V relay with a 110V pull, hooked up to a normal X10 switch controller. So from an X10 remote in the house, or via an sms gateway, we could turn on our hot tub remotely.

This had a few advantages including: 1) this setup was more accurate than the ancient thermal sensor/control on the hot tub 2) we never again had a large electric bill because someone forgot to turn it off and 3) really nice for when a date is going well and you can turn on the hot tub ahead of time :)

Would have been a nice addition to the BBB bubbler [1]. - a current UM grad student

[1]https://www.beyster.com/blog/?p=303

You are a hero. This made me chuckle. Thank you for existing, human.

If you want to use this as a toy, sure. But please don’t rely on it for messages you want to actually get delivered: These gateways frequently drop messages for random reasons, or block your IP if you send more than a few messages at a time. Also, in countries other than the US, expect the gateways to be long gone, or completely unreliable.

This so much!!

I work with HVAC software and so many of our customers want important alarms on their mobile devices. They don't want it in email because nobody has notifications on for email so they want a text and they are aware of the carriers SMS gateway. Five years ago this worked ok but with the rising spam wars these similar alerts we send out get caught up in spam filters easily and customers blame us.

It is very simple to use something like pushover and API alarm delivery to them, and so much more reliable. Still it's shocking to see; wait that requires us to pay pushover? Nah, we'll take our chances with email@SMS for our multi million dollar chiller plant in our hospital alarm notifications.

Exactly. That's why you don't want to use these free open relays, ever, for anything that you actually want to get delivered. There are a lot of companies out there that specialize in SMS delivery and have built really smart/complex route selection, retry, failure handling and cost optimization logic to get to a reasonably high delivery %.

/spam: my friend runs https://messente.com that specializes in global SMS delivery and they are, honestly, quite good at it. (Let me know if you ever start using them so I can let him buy me a referral-beer at the pub)

Thanks for the heads up. I want to create this as one of my mini-projects, and you help me with some future questions I might ask shortly.

And if it's not important you can send an email to an SMS gateway for (most?) providers. Google the addresses.

Also: SMS has zero delivery guarantees. SMS providers can completely legitimately drop your SMS on the floor.

Tangentially related: it's fascinating how much of the cellular messaging network runs on (or at least speaks) SMTP and IMAP. These SMS/MMS gateways are just one example; Visual Voicemail[1] also runs on IMAP and it also shows up in mobile terminal (i.e., phone) testing standards[2].

[1]: https://www.gsma.com/newsroom/wp-content/uploads/2012/03/omt...

[2]: http://www.omtp.org/OMTP_Terminal_Testing_1.0.pdf

This is just an outside interface, the actual networks don't run on SMTP and IMAP in any way, rather, it's things like SS7 (https://en.wikipedia.org/wiki/Signalling_System_No._7) and SMPP (https://en.wikipedia.org/wiki/Short_Message_Peer-to-Peer)

So the article is actually about how to send an email with python because the carriers do the text message part.

And only in select regions - most international carriers don't offer an email gateway. I'm not surprised the YouTube thumbnail looks the way it does, this is attention-grabbing at best and deceptive at worst.

Or the article is about how to call a function in Python because smtplib does the email part. I mean, you make the thing happen, I don't really understand why you draw this distinction (or where you would stop).

Because the main part of the article is about sending a mail with python and the actual method to send an SMS is just send a mail to a specific mail address.

So put that on top and you can ignore the remaining 90% of the article.

It doesn't even mention that this method could lead to costs for the recipient.

For instance in germany you have to activate that feature for t-mobile numbers and they charge you for received emails per SMS

Sure, it's a little long, and I was also disappointed that it presented a method I was already familiar with. However claiming that it's not sending SMS because you make something else send the SMS is a dishonest.

literally the second half of the title is "Use Python to send text messages via email", how much further on top would you want it to be placed?

There is also interesting information about the carrier APIs. Honestly, the article was helpful.

The only info I felt was missing is how to retrieve the carrier when given a phone number.

Aren't these basically open relays for SMS? Wouldn't they be buried under an avalanche of spam? I'm honestly mystified at how and why carriers expose these free SMS gateways. Am I missing something?

I used to work for a big public organisation, we had numerous SMS providers over the years. Most of them used HTTP (notice the lacking S) as the protocol and accepted simple POST actions with a key in the header (for everyone listening to read). When I left the service we used the most had moved to HTTPS by our request, but functioned the same way and was essentially bruteforceable because our password was 4 characters long and there was no limit on the service. I left in 2021.

I don’t think security is necessarily the most important thing to these companies.

Rate limiting.

About a decade back, we used to use the email approach at a non-profit I volunteered at. Annually we would need to send a bunch of texts of a short time period. Think "once a year event".

Eventually we had to stop using that solution. Most texts went through, but there were enough failures that we had to switch to twilio. I can't remember when; I guess 5 or 10 years ago? Getting old.

(We didn't immediately switch to twilio. There was one year during which we used my personal phone to send out an obscene number of texts from my personal phone number. Figured out that was a bad idea pretty quick.)

What went wrong with using your personal phone? Was your provider upset?

Two issues:

1. Latency. We really needed messages to go out to everyone all at once.

2. My personal phone became unusable for the rest of the event because people thought that number was a general event organizer contact mechanism. This was a big deal because I was a key member of the operations staff and really needed my phone to be useful.

Solving (1) and (2) was certainly doable, but twilio solved the problem for us and I had higher impact IT stuff to be working on for the org.

They’ve been sitting there, open, for a really long time — probably close to two decades. Maybe longer? It’s an arcane enough feature that they’d probably just kill the service altogether of they became problematic. Can be convenient for hobby dev projects.

Back around 1998 I built a Nokia phone and interface in Flash 4 that you could actually use to send me an SMS message using this exact technique behind the scenes. Unfortunately it was interesting and novel enough that it made German TV and while sat at my desk one morning my phone suddenly started buzzing constantly as a non-stop flood of messages in German started coming in. I had to turn the phone off and when I turned it back on after work it buzzed until it basically filled up and then never worked again. I had to buy a new phone and disable the message sending of the Flash site.

Can anyone help me understand why carriers still offer these gateways for free? I would have thought they would charge for them?

They are mostly obsolete. They might be useful for low-volume, low-priority messages or hobbies, but delivery is inconsistent. Sometimes they take a while to deliver, they often get dropped or throttled.

I worked with an app that sent weather alerts to subscribers and had used these gateways. It wasn't very high volume, only sent messages during active storms in the subscriber's area, and not more than one every 10 minutes or so. We hardly ever sent more than 100 messages in an hour for all subscribers, even during a heavy storm period. Still we encouraged users to use a push messaging app like pushover which we integrated with, since sms through smtp often didn't deliver or took hours to arrive. We considered setting up a real sms service like twilio but the push messaging apps had better features than sms anyway, so the sms over smtp option was just a hack for users that really wanted sms.

In 2011 they worked pretty well, but by 2018 they were frequently down or didn't work properly. Pretty sure that messages sent through them are much more likely to hit spam filters or get rejected for whatever reason.

This isn't a full answer, but I know of a few "smart" appliances out there that use these gateways to deliver messages. The washing machines in my college apartment (which were otherwise extremely dumb) did for some reason.

The amount of traffic that goes through these gateways probably isn't worth charging for, given the amount of headache it would cause for incidental uses like the above. But it would probably cut down on gateway spam, which seems to have increased lately (at least on AT&T).

Many SMS pay-per-use plans charge per message received.

Seems like a vulnerability, what's stopping someone from being targeted with thousands of inbound SMS messages that they suddenly have to pay for?

What's to stop somebody's website from being targeted with millions of inbound requests which causes their CDN bill to explode?

That's a major difference between the US and the rest of the world.

In the US the recepient of a mobile call and obviously also an SMS pays. Either per use or as part of a package.

In the rest of the world the recepient pays absolutely nothing, the orginator pays either per use or by package.

So such gateways make sense for US-providers. But no sense in the rest of the world. Very few did always exist during the last 20 years even in the rest of the world. I tried to use them years ago and failure rate was something like 90% or more. If something is too good to be true it's typically not true.

Seriously? Last time I saw such a plan was 2008 and even then it was only that one provider...

Off the top of my head, Tracfone still operates like this in the US. As of 2018, they were selling service in "minutes", where one minute is also equivalent to 3 SMS or 1KB of data. The most common denomination is a 60 minute card for $20 (with a 90 day expiration), but in practice, many subscribers have a doubled minutes benefit for everything they add. They also have "just texts" and "just data" cards which offer better rates for those categories of service.

Tracfone targets themselves very narrowly at the "elderly and only want to pay for what I'll use/just want an emergency phone" demographic. If the subscriber is going to use the phone approximately at all, those are garbage rates, but if you only want to keep the lights on, $20/3 per month is about as cheap as it gets.

I always assumed they were just a vestige. I imagine the top brass at most carriers don't even know this exists.

compelled by law

I hate everything about this article. From the video thumbnail to the misleading claims.

The thumbnail looks really out of place, if I saw it in my Youtube feed it would be "acceptable" but in a blog format it looks insane.

What's misleading about it?

You're sending an email, not a SMS. That's the popular interpretation of "text messages". Also it may be free for you to send (because it's not a SMS) but not free for your recipient depending on their carrier/plan.

Here is Twilio's official docs (arguably the most popular platform in that field): https://www.twilio.com/blog/how-to-send-sms-online Would you say that it's misleading because you are actually sending an HTTP request, not an SMS? If you use the Python wrapper, would you say what you're doing is calling a Python function, not sending an SMS?

Do you think their pricing page is incorrect, because it doesn't include the price the recipient might have to pay, for each possible carrier they might be using?

I mean, where do you stop? When you pay your ISP, should the bill show "pushing the button to activate your connection", rather "internet service"? Should coffee shop include the cost of a bottle of water, because drinking coffee will dehydrate you? I don't understand what you expect.

I see your point, but I think rather than it being misleading, you're just interpreting it differently. The way I see it since the recipient is receiving a text - that's using the SMS protocol even if it is through a gateway. The result doesn't change.

As to the second point, yes - I did mean free for the sender. I assumed that people were aware that the recipient can still be charged. I mean by the same logic, you might as well add the recipient's phone bill (if they don't pay per SMS message individually) and even the cost of their phone if you want to be picky. I don't think anything is inherently free. We just have different interpretations.

At the end of the day, I just thought the idea was cool, so I wanted to share it hoping someone might find it useful.

I skimmed the post but couldn't find out how one would know what provider to use. I guess you could ask whoever you're texting with but that's not very reliable, not everyone knows, and people change their provider.

Twilio has an API to identify the provider. https://www.twilio.com/docs/lookup/api

Still costs money, but if you're sending a lot of messages, this would substantially reduce the costs.

"Twilio has an API to identify the provider ..."

  curl -s -X GET "https://lookups.twilio.com/v1/PhoneNumbers/$number?Type=carrier&Type=caller-name" -u $accountsid:$authtoken | /usr/local/bin/jq '.'

If you're sending a lot of messages through one of those, you can expect to be blocked pretty quickly unfortunately.

Just try them all...

This is a good point. With that said, one does not necessarily need to know the provider, it just makes the process more direct. An alternative approach is to send a message to every provider using the same number. The invalid addresses will likely bounce back, but the correct match will go through.

Definitely don't use your Gmail account to send them then unless you want to end up as one of those people that got their account suspended.

I’m wondering if it is possible to find a list of provider emails from other countries such as BraZil.

I mentioned this website in the post. It has a list of providers for different countries (Brazil included). I don't know how up-to-date they are, but it might be a good starting point. You can also always try contacting the carriers directly. https://email2sms.info/

Thank you, what I missed is how you do to find out for other providers. In Brazil you covered 50% of the carriers. But how can I help you to find out the other ones and update the information for you. Should I contact the providers and ask for it and send a Pull Request?

Again, thank you for putting this into a post!

"I skimmed the post but couldn't find out how one would know what provider to use."

I personally do carrier lookups in the unix shell with a 'curl' command using the Twilio API (see my other comment under you).

However, you can just look this information up on a number of different websites:

https://www.freecarrierlookup.com/

... et. al ...

Some countries allocate set prefixes to carriers which can be reliable if number porting doesn't enter the equation:

https://en.m.wikipedia.org/wiki/List_of_mobile_telephone_pre...

That list isn't very useful in this context unfortunately. There is no reliable mapping between area code and provider in North America.

That's why my first two words were "some countries". The US is but one.

Until the number gets ported to a different provider..

Oh, wow. Which is why my last 7 words were "if number porting doesn't enter the equation"

:) Brings back memories of doing this in 2002 to blast out Student Government campaign messages to students on campus. Back then email servers were very forgiving. I just had a loop that generated all combinations of <phone-number@carrier-x> and send out an email from a campus IP address via sendmail. It was a very effective way to send notifications at almost zero cost.

I did this in college, but with personal contacts because I couldn't afford a data plan at the time or a smart phone. I'd carry my laptop around the mall or connect to random open wi-fis from hotels to email people's phones. All to save a few bucks.

Man, I remember doing this around a decade ago back before some of my friends abroad had smart phones, being able to message them when they were away from their computers had such a fun novelty to it.

Here's a fun story from back in the decade-ago-ish days: My wife couldn't stand cellphones, so I got her hooked on Google Voice for texting, which was great -- texts would show up in the gmail inbox, and you could just reply to them like emails. Calls were forwarded to the landline, voicemails showed up as attachments. Elegant, and free.

She was also hooked on the brand new "Kindle Keyboard 3G", which came with unlimited cellular data so you'd be able to buy ebooks at any time, without wifi. It also had a primative web browser that was capable (just barely) of running the gmail web interface... so voila, it's actually an e-ink tablet, with email and SMS capability! She'd have to manually load the kindle browser to check for messages -- great, really, because who wants to be interrupted with a notification while reading a book?

But after a few semi-urgent texts went unnoticed, I dreamed up a solution: change the Kindle's name based on the number of unread texts. This wouldn't interrupt reading, but it would be visible on the kindle's home screen, a good compromise.

So I hacked up a python/applescript/firefox script running on my mac mini home server. every 5 minutes it would log into her gmail account, check for unread text messages in the gmail inbox, and then log into her amazon account and update the kindle's name from "Wife's Kindle" to "Wife's Kindle (x)". It was beautiful. It worked!

It didn't work forever. Eventually the gmail web app was updated with too much javascript for the kindle browser to handle. Eventually that kindle broke. Eventually the mac mini died too. But for a while I had a full 3/5ths of FAANG cooperating for my little kindle hack. Fun times.

Have you tried the Gmail plain HTML version? I use it because it loads so much faster and without any JavaScript: https://support.google.com/mail/answer/15049?hl=en

This is such a fun story, thanks for sharing!

I think with all the technological abundance we have now, we often forget the fun/creativity that limitations can impose on us.

Personal automation at its finest.

This is clever but due to the astounding amounts of spam and scams I got through that mechanism (not this script specifically), I had to set this to blocked on my T-Mobile account.

I wasn't aware you could block email-based messages. I did a quick online search, but didn't find any T-mobile documentation for this. Do you when're I can learn more about it?

If you log into your My T-Mobile and go to Profile, your line, Blocking, Other there's an option to "Block Tmomail.net Messages."

I recently did exactly the same. Sadly, the local library system uses these gateways, but that's a sacrifice I was willing to make to cut out a ridiculous amount of spam.

Let me point out that receiving Telecoms are well aware and block randomly or totally messages from these services so that they appear buggy.

We used to offer such a free SMS gateway at ActiveXperts.com. Now moved to AuronSoftware.com and hid it a little better.

It's meant for trial users to be able to test our software without having to have a subscription or GSM modem.

But those gateways saw / see a lot of abuse. Even though we clearly state that each trial user only has 10 free messages we still regularly get an e-mail from an angry 'trial user' because only 10 messages out their 50K+ phone number mass mailing arrived.

This article reminded me of years past when I would marvel at the Nokia 6110 and how easy it was to send text messages while exchanging message centre numbers that gave me and my friends the ability to send unlimited messages for free.

Back during my phd I worked in a project that set up sms transponders onto the handles of water handpumps in kenya.

So whenever a pump was misbehaving or broke, we would observe it all on a webpage and a technician would be alerted to fix it.

Later on some ML was strapped to the SMS data to predict failing pumps before they failed.

Good stuff. sms can be very powerful in the right setting.

Don't know what the author means by free here though. Sms is something you pay for, one way or another.

The primary limitation here is inability to receive responses back from users. From a business revenue generation angle, that's probably not enough of a feature set to monetize for the carriers.

I'm not sure whether it's universally supported, but AT&T at the least actually does support responses. I can text any email address from iMessage and receive an email via SMTP from 1234567890@mms.att.net, and responding to that email also delivers correctly (and is even threaded).

Edit: One funny thing is that iMessage will detect gateway traffic from/to email addresses that are tied to iMessage accounts, and put those into a "blue bubble" chat instead of the normal SMS/MMS "green bubble" chat.

You can reply to these messages and it goes back to the email that sent them. At least on my carrier.

I can also verify that replies work (using T-mobile).

Not only can you reply, but you can compose new messages using an email address as a recipient.

Warning: that page plays sound. How can they not know that’s not done?

Don’t ask your customer for their carrier information. Just use sms

I remember in the UK in the 90's you used to be able to set your phone's SMS message centre to one in EG Finland or somewhere and be able to send all your texts for free.

Can we talk about how the function he wrote had like 15 parameters?

I used to forward all my hotmail to sms in 1997. I felt so techy doing email on my little flip phone.

Idea for a better title: the subtitle "Use Python to send text messages via email"

I do think that's more descriptive, but thinking about it from a search perspective, I feel that's less likely to be searched.

For free? What's the catch?

On the sending side, there are two catches: you need to know which gateway to connect to (which in turn generally costs money), and your messages look even sketchier than "normal" short-number SMSes.

On the receiving side: there isn't any real delivery guarantee for SMS/MMS gateways. You're basically depending on a mostly forgotten and probably neglected service (and probably physical server) at each carrier to receive potentially important information.

Edit: You can also get around the gateway identification problem by spamming every gateway with your message. That worked pretty well when I tried it last (around 5 years ago). But I wouldn't be surprised if continually doing that earns you a hellban from every carrier.

You have be in the US. These email to SMS gateways all shutdown 15 years ago in other countries. I suspect the US keep them because providers handle billing differently. Unlimited SMS as been include in most subscriptions for more than a decade here, but some Americans still pay to receive texts. So in the US there’s still a finacial motivation to keep them. That and the US seems to be rather slow to move of certain outdated solution.

You have to use Python (I kid)

Massive amounts of SMS spam.

sadly, this seems just to work for the US, my country (in the EU) does not have such free services anymore, there used to be such a service in the 90s, unfortunately it has been discontinued

So, how do you lookup a phone number's provider for free?

Not free for meaningful numbers of requests, but I've used APIs like numverify[1] to do this before. There are probably per-carrier APIs you can request access to.

[1]: https://numverify.com/

Not the most scientific approach, but you could send a message to every provider using the same number. If you get a "message not received" bounce back, then that's a good indication of which carriers are not the correct carrier.

That was what I came to checkout the code for, thinking they put some cool logic in there.

Is there a way to send free SMS in Australia?

The article links to a site that links to this list, which includes Australia:

https://github.com/mfitzp/List_of_SMS_gateways/blob/master/s...

Reply on news.ycombinator.com