Tim X
4/24/2007 10:15:00 AM
david <savatagedg@hotmail.com> writes:
> I know Ruby can do a lot of neat stuff, I was just wondering if someone
> has found a way to read emails from a gmail account. The reason is I'm
> hoping to create a system that a user can email an account with a
> command, and Ruby will read it and exacute that command. Any ideas /
> suggestions?
>
Well, this can be done and in fact has been done before many times. In
principal, this is not very different in concept from mail lists which allow
you to send commands to the list server to subscribe, unsubscribe or get
information on a particular list etc. In fact, back before the web and http,
systems that used e-mail to initiate some action/command were fairly common.
However, they soon whent out of vogue as various limitations became problematic
with the growth of the Internet and more malicious activity.
I'd really consider a few things -
1. E-Mail is an inherently insecure mode of communication.
2. You have no control over who sends messages to the e-mail address.
3. Depending on what sort of commands you want executed, you will need some
sort of security/authorisation framework, but due to point 1 above, you are
never going to have a really secure system.
I believe gmail allows retrieval of mail via imap/pop as well as access via the
web interface. Therefore, you could retrieve the messages using this method and
then the problem becomes one of parsing the message to get the command. To make
this process easier, you can either find an existing ruby library for parsing
mail messages or simply do it yourself (the basic mail message format is fairly
trivial). To make the parsing easier, you could require commands be somehow
tagged or otherwise marked to make it easy to extract.
I'm too much of a ruby newbie to point you to existing libraries you could use,
but I'm sure there are some out there which will do most of the work. However,
apart from doing this just to see if you can, I can't see any real benefit. You
would probably be better off putting effort into something else.
Tim
P.S. I actually wrote a system using Tcl some (too many!) years back which used
e-mail to "move" a software agent from one host to another. Essentially, the
agent (a fairly simple Tcl script) wrote its state variables into a file which
was fairly well defined in structure, then sent that file to an e-mail address.
The message was retrieved from the mailbox via pop, stripped of its headers etc
and passed to another Tcl script that worked as a loader. The loader
essentially started a local Tcl agent and set its state to be the values from
the e-mail message. The new Tcl script then continued execution on that new
host.
This was really just a proof of concept relating to software agents and
serialisable objects (a very primitive form - this is early 90s before Java and
other languages had such facilities). I used this very primitive system to
perform data searches on groups of servers (network connectivity was a lot less
back then and remote searches could be more expensive). Essentially, you could
specify the information you wanted (in a very primitive way), the hosts you
wanted to search and the agent would start. It would "send itself" to the first
host and start searching for data that matched your criteria. any it found, it
would put into one of its state variables. When it finished on that host, it
would send itself to the next host and repeat the process. After doing this
with all hosts, it would send itself "home", where it would pop up a dialog
window (using Tcl/Tk) displaying the results. At the time, I used e-mail
because it was one of the few platform independent communication facilities
other than writing your own server client system at the Tcl level and then you
had to deal with different hardware issues depending on the platform etc. Of
course, as the agents were in Tcl, all platforms had to have a Tcl interpreter
anyway.
It was fun, but really was not practicle even back then. Of course, now there
are lots of other approaches that could be used, such as the many OO languages
which have built in support for serialising objects and pushing them across a
network. Reflection and other mechanisms which are now much more common also
provide additional power.
--
tcross (at) rapttech dot com dot au