
Show HN: Email controlled gate opener in 20 lines of shell - andrewchambers
http://acha.ninja/email_controlled_gate.html
======
vog
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.

~~~
andrewchambers
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.

~~~
vog
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.

~~~
andrewchambers
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.

------
zbentley
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](https://stackoverflow.com/questions/27134018)

\- Or via curl: [https://debian-
administration.org/article/726/Performing_IMA...](https://debian-
administration.org/article/726/Performing_IMAP_queries_via_curl)

\- Or talking POP3 via telnet: [https://www.shellhacks.com/retrieve-email-
pop3-server-comman...](https://www.shellhacks.com/retrieve-email-pop3-server-
command-line/)

\- Or get POP3 messages via pure Bash and a little Perl:
[https://gist.github.com/xionluhnis/4712075](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.

------
StavrosK
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...](https://www.stavros.io/posts/how-remote-control-rf-devices-
raspberry-pi/)

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...](https://www.stavros.io/posts/building-cheap-home-
sensorcontroller/)

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/](https://www.makerfol.io/)

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

~~~
rando444
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.

------
chrismorgan
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](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!)

~~~
vog
_> 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.

~~~
chrismorgan
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.

~~~
andrewchambers
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.

~~~
vog
_> 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.

