I find the title misleading, because this first of all about a new web service the author wants to promote, and not about the elegance of a tiny shell script. (At least the article sets this straight in the first paragraph.)
The title suggests that it is all standard Unix tools plus 20 lines shell, and that all you need is a working mail server.
However, that setup requires in addition:
1) a command line tool "wsemail" for email handling, which is ~100 lines of Go code. (by the same author)
2) Cross-Compiling that tool from source for the Raspberry Pi.
And even that tool also doesn't handle email itself, instead it accesses:
3) a separate web service "websocket.email" (by the same author)
4) Requesting an API token for that web service.
If this was really about minimalism (as the title suggests), I would have expected polling a mail account via POP3, or opening a persistent IMAP connection to the mail server, all handled locally by the Raspberry Pi.
That's a valid interpretation and criticism. I was actually hoping Socat would have a websocket mode to eliminate some steps.
My take on it is that you only need to write 20 lines of code to do an email triggered action because I spent some time configuring the tedious parts. At the same time, I thought it would be fun to show people that the real world and linux shell are not so far from interacting with each other.
Why not running an IMAP client on the device? (e.g. fetchmail, or anything else that speaks IMAP)
If you spend 100 lines on a separate Go program, you could as well make it a generic IMAP client (using some Go libraries) rather than making it a HTTP/Websocket client that is highly specialiced to a single web service.
That sounds like a good solution, though I'm using the websocket aspect for throw away addresses in integrations tests where this seemed to make sense.
The wsemail tool seems useful, but definitely not as ubiquitous as "shell". There are a few other ways you could poll for email using the shell plus some very common tools, many of which are likely packaged for or already distributed on a lot of common "micro" linux deployments for microcontrollers and the like. In the author's defense, they'd probably require a few more than 20 lines of shell in order to be in any way robust:
That last one really is quite interesting, since it looks like you could abandon Perl for parsing entirely if your goal was "just check for the 'open sesame' string anywhere in the email blob", after which (if my reading of the gist is correct) you'd be using pure Bash and shell builtins, and it wouldn't be much longer than 20ln.
Yet another also, I'm working on a side project where makers can showcase their projects, and I'd love it if you considered it for this or your other writeups:
But seriously, it is pretty neat as a proof of concept!
I just wouldn't want to spend a lot of time counting on something like this. I've bloodied my fingers trying to pull out the cotter pin on the ranch gate where I used to work plenty of times, because the RF opener wasn't working.
I know your comment is mostly tongue-in-cheek, as presumably you'd have an extra opener.
One extra idea here would be to integrate this with IFTTT or something similar where you tell it to send an e-mail automatically when you reach a certain location. (not sure how accurate this would be)
or to create some sort of macro on your phone to use a voice command to send a pre-set e-mail.
I was expecting this to use a genuine mail server on the target device, because that actually wouldn’t be very difficult—configuring a mailbox to deliver messages to a program is standard fare for a mail server. For that matter, you could write the entire thing in a Sieve script (filter messages containing “open sesame”, and then execute such-and-such a program, so long as your server includes some way of executing a program in a Sieve script, such as Dovecot’s vnd.dovecot.execute extension).
Still, since we’re going with the “do everything over the web!” route—
With JMAP, you’ll be able to use plain old HTTP Event Source to listen for emails if you want (http://jmap.io/spec-core.html#push) without the need for a third-party service, though that will just tell you “there’s a new message” and you’ll have to fetch it through a normal JMAP request (getMessages, that would be).
This will still probably be out of scope for pure shell scripting, but it won’t require much code, just a decent HTTP library. I haven’t really thought about it—maybe you could string something together with cURL and a bit of piping.
(I work for FastMail and we’re sponsoring JMAP development. It’s coming along nicely, and I believe we plan to take our JMAP implementation live fairly soon. I’m sure we’d love to hear about people making toys like this with it!)
My API is quite simple, you connect to api.websocket.email/v1/subscribe with a websocket an an HTTP header. It just saves a bit of time when you don't want to read specs like that, maintain a server, or setup credentials.
At some point it makes sense to setup your own servers though. It's up to the individual to decide. I just wanted a way to write some unit tests, had to setup an email server, then made my test interface public.
You could do it that way, but (a) it’s much more satisfying to have it run the mail server itself, and (b) it’ll be markedly faster because the message is going to the server rather than to a third-party server, which will then notify your device.
POP3 is a polling protocol, so you can’t realistically use it for anything real-time. For IMAP, your server probably supports IDLE, and you’ll need to use a client that supports IDLE as well. I’m not familiar with what’s available in IMAP client libraries; people put most of their email client effort into user agents.
Everything IoT should run its own mail server, just for the fun of it. Bonus marks if it causes an RCE vulnerability. (But I’d say you’re pretty safe from that with Dovecot.)
But seriously, email servers aren’t actually that scary. I wish more people ran their own, and more developers could comfortably work with them. Especially as an endpoint for something like this, running your own email server is perfectly feasible and reasonable—it’ll only accept messages to one mailbox, which will be immediately processed and discarded, so there’s no storage. It’s simply a C&C module.
I'd love to see some of your IT homework projects, they sound fun.
Though in all seriousness, I think the novelty is that even my parents understand email. If I told them to email an address, they could do it. They would almost certainly fail to install an IOT remote control app and configure it correctly.
I find the title misleading, because this first of all about a new web service the author wants to promote, and not about the elegance of a tiny shell script. (At least the article sets this straight in the first paragraph.)
The title suggests that it is all standard Unix tools plus 20 lines shell, and that all you need is a working mail server.
However, that setup requires in addition:
1) a command line tool "wsemail" for email handling, which is ~100 lines of Go code. (by the same author)
2) Cross-Compiling that tool from source for the Raspberry Pi.
And even that tool also doesn't handle email itself, instead it accesses:
3) a separate web service "websocket.email" (by the same author)
4) Requesting an API token for that web service.
If this was really about minimalism (as the title suggests), I would have expected polling a mail account via POP3, or opening a persistent IMAP connection to the mail server, all handled locally by the Raspberry Pi.
That's a valid interpretation and criticism. I was actually hoping Socat would have a websocket mode to eliminate some steps.
My take on it is that you only need to write 20 lines of code to do an email triggered action because I spent some time configuring the tedious parts. At the same time, I thought it would be fun to show people that the real world and linux shell are not so far from interacting with each other.
Why not running an IMAP client on the device? (e.g. fetchmail, or anything else that speaks IMAP)
If you spend 100 lines on a separate Go program, you could as well make it a generic IMAP client (using some Go libraries) rather than making it a HTTP/Websocket client that is highly specialiced to a single web service.
That sounds like a good solution, though I'm using the websocket aspect for throw away addresses in integrations tests where this seemed to make sense.
The wsemail tool seems useful, but definitely not as ubiquitous as "shell". There are a few other ways you could poll for email using the shell plus some very common tools, many of which are likely packaged for or already distributed on a lot of common "micro" linux deployments for microcontrollers and the like. In the author's defense, they'd probably require a few more than 20 lines of shell in order to be in any way robust:
- Connecting to IMAP via openssl: https://stackoverflow.com/questions/27134018
- Or via curl: https://debian-administration.org/article/726/Performing_IMA...
- Or talking POP3 via telnet: https://www.shellhacks.com/retrieve-email-pop3-server-comman...
- Or get POP3 messages via pure Bash and a little Perl: https://gist.github.com/xionluhnis/4712075
That last one really is quite interesting, since it looks like you could abandon Perl for parsing entirely if your goal was "just check for the 'open sesame' string anywhere in the email blob", after which (if my reading of the gist is correct) you'd be using pure Bash and shell builtins, and it wouldn't be much longer than 20ln.
That's a cool hack. Instead of a Raspberry Pi and remote, I used an ESP8266 and an RF module for mine, with a writeup here:
https://www.stavros.io/posts/how-remote-control-rf-devices-r...
I also designed a PCB for it, and have uploaded code for sending arbitrary IR/RF codes: https://www.stavros.io/posts/building-cheap-home-sensorcontr...
Yet another also, I'm working on a side project where makers can showcase their projects, and I'd love it if you considered it for this or your other writeups:
https://www.makerfol.io/
Sweet, now I can wait outside my gate until:
- Internet connectivity is restored via my ISP.
- My phone charges so I can send an email.
- My mail relay unclogs/restarts/gets fixed.
But seriously, it is pretty neat as a proof of concept!
I just wouldn't want to spend a lot of time counting on something like this. I've bloodied my fingers trying to pull out the cotter pin on the ranch gate where I used to work plenty of times, because the RF opener wasn't working.
I know your comment is mostly tongue-in-cheek, as presumably you'd have an extra opener.
One extra idea here would be to integrate this with IFTTT or something similar where you tell it to send an e-mail automatically when you reach a certain location. (not sure how accurate this would be)
or to create some sort of macro on your phone to use a voice command to send a pre-set e-mail.
I agree, only 3 critical flaws! ten times better than existing internet controlled products, you are selling it for me. :)
I was expecting this to use a genuine mail server on the target device, because that actually wouldn’t be very difficult—configuring a mailbox to deliver messages to a program is standard fare for a mail server. For that matter, you could write the entire thing in a Sieve script (filter messages containing “open sesame”, and then execute such-and-such a program, so long as your server includes some way of executing a program in a Sieve script, such as Dovecot’s vnd.dovecot.execute extension).
Still, since we’re going with the “do everything over the web!” route—
With JMAP, you’ll be able to use plain old HTTP Event Source to listen for emails if you want (http://jmap.io/spec-core.html#push) without the need for a third-party service, though that will just tell you “there’s a new message” and you’ll have to fetch it through a normal JMAP request (getMessages, that would be).
This will still probably be out of scope for pure shell scripting, but it won’t require much code, just a decent HTTP library. I haven’t really thought about it—maybe you could string something together with cURL and a bit of piping.
(I work for FastMail and we’re sponsoring JMAP development. It’s coming along nicely, and I believe we plan to take our JMAP implementation live fairly soon. I’m sure we’d love to hear about people making toys like this with it!)
My API is quite simple, you connect to api.websocket.email/v1/subscribe with a websocket an an HTTP header. It just saves a bit of time when you don't want to read specs like that, maintain a server, or setup credentials.
At some point it makes sense to setup your own servers though. It's up to the individual to decide. I just wanted a way to write some unit tests, had to setup an email server, then made my test interface public.
> configuring a mailbox to deliver messages to a program is standard fare for a mail server
Why?! Why would you run a separate mail server of that device?
All you need is IMAP (or POP3), to connect the device to an existing mail server.
You could do it that way, but (a) it’s much more satisfying to have it run the mail server itself, and (b) it’ll be markedly faster because the message is going to the server rather than to a third-party server, which will then notify your device.
POP3 is a polling protocol, so you can’t realistically use it for anything real-time. For IMAP, your server probably supports IDLE, and you’ll need to use a client that supports IDLE as well. I’m not familiar with what’s available in IMAP client libraries; people put most of their email client effort into user agents.
Everything IoT should run its own mail server, just for the fun of it. Bonus marks if it causes an RCE vulnerability. (But I’d say you’re pretty safe from that with Dovecot.)
But seriously, email servers aren’t actually that scary. I wish more people ran their own, and more developers could comfortably work with them. Especially as an endpoint for something like this, running your own email server is perfectly feasible and reasonable—it’ll only accept messages to one mailbox, which will be immediately processed and discarded, so there’s no storage. It’s simply a C&C module.
Would need some way to get through NAT, at least here.
Maybe ngrok will work with smtp too.
I find the thought using email for IOT pub sub hilarious no matter how you do it.
> Would need some way to get through NAT, at least here.
And you need to setup DynDNS or similar.
Having a persistent IMAP connection sounds much less troublesome to me.
I like how a boring 6th grade level IT homework gets a lot of attention just because it controls a physical thing - gate in this example.
I'd love to see some of your IT homework projects, they sound fun.
Though in all seriousness, I think the novelty is that even my parents understand email. If I told them to email an address, they could do it. They would almost certainly fail to install an IOT remote control app and configure it correctly.