E-mail as a System Console. Part I

Accessing your home system from work or from around the world, using fetchmail, procmail and a few scripts.

Editors' Note: The following is a chapter from the book Multitool Linux, written by Michael Schwarz, Jeremy Anderson, Peter Curtis and Steven Murphy. Consult the book's web site for links, updates and errata.

Question: How can I get access to my home Linux system when I'm 1)at work behind a firewall that only allows me to send e-mail from my workstation or 2)away on a business trip and the hotel firewall only allows me to surf the Web?

Answer: Create an e-mail-based console application that let's you execute commands and return results via e-mail. If you're stuck with only web access, get a web e-mail account somewhere and use it to send commands over e-mail to your system at home. The e-mail console is a nice way to communicate with your system when normal communications (Telnet, ssh, FTP, what-have-you) are not available.

Have you ever been sitting around at work and wished you could execute a command on your home Linux system to find some information? I have and I bet you could find lots of reasons why you would want to do this as well. E-mail is simple, yet powerful. But can it be used as a console to your home Linux system? You bet! I use it all the time.

But why not just log in and execute commands in the traditional manner? Sure, I could do that, but that would be no fun. In addition, there are times when direct access to a system is not available. But if e-mail is available, then this e-mail console application will work for you. First, I'll tell you about how I arrived at developing the e-mail console, then I'll share how I did it.

My Disconnected System

If you're like me, at one time you probably connected to the Internet using a standard phone line and a local ISP. I like my ISP, but they limit the number of hours I can be on-line each month and charge me big bucks when I go over that limit. I won't switch ISP's because they are, without a doubt, the best in my area. Because of this restriction to my on-line adventures, I pick and choose the times when my Linux system will be on-line fetching e-mail, downloading files and so forth. The problem I have with this situation is I want access to my home system when I am at work. And when I'm at work, I often find myself needing to access my home system to get a file. With my monthly limit, I can't simply leave my computer continuously connected to the Internet during the day. What I need is a way to keep my home system off-line until I need it and then have it go on-line and stay that way until I tell it to disconnect.

Some time ago I decided to make it so my system would periodically connect to the Internet and download e-mail from my ISP using a nifty program called fetchmail. I wrote a few Perl scripts to automate and synchronize the connection requests from various applications, including SETI@HOME and fetchmail, which both need to connect to the Internet at various times. Plus, I needed to go on-line to surf around but not get disconnected when the fetchmail utility completed its work. Getting e-mail with fetchmail allows me to spend as little connection time as possible getting and responding to e-mail—why waste connection time typing replies?

The main goal of these scripts is to coordinate the connection and disconnection requests and keep my system on-line when needed. It then occurred to me that if I could somehow send an e-mail to my system (which picked up e-mail once an hour) and somehow have that e-mail parsed, so a command could be executed, I could tell my system to stay on-line or disconnect. Bingo! Now all I had to do was find that e-mail parsing, command-executing, dream utility. The solution was right under my keyboard.

Getting Connected

On a piece of paper beneath my keyboard was a list of utilities I thought might be useful for dealing with my e-mail; procmail was one of them. Procmail, as it turns out, is an incredibly useful utility for performing searches on incoming e-mail and then performing some kind of action. Currently, I use procmail to parse my incoming e-mail every 15 minutes (I changed it from an hour down to 15 minutes so I wouldn't have to wait so long to access my system). It executes the command that tells my system to stay on-line after it is done fetching e-mail. Now, I can send e-mail to my home system with a special subject like “CONNECT REMOTE”, and my system will simply stay on-line after fetching and processing all the e-mail from my ISP. In my procmail configuration file, a recipe file, I searched for this string and then executed the Perl script I had written to make it so my system stayed on-line. I could also tell it to disconnect. Once I had this set up, it occurred to me that with a little more work, I could write a procmail recipe and Perl script that would execute any arbitrary command I gave it. This was the coolest thing I had ever heard of, and my &quote;NT&quote; friends would be so jealous!



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: E-mail as a System Console. Part I

Anonymous's picture

There is a program called xringd that makes your computer perform actions when you "call it on the phone" (ring the line the modem's one) in specific patterns - for example, 2 rings at a distance of 10 seconds and then one ring after 20 seconds.

This way, your computer can be made to connect to the Internet from any phone anywhere. Not easy, but works.

Another possibility... if you have a modem with Caller ID (it must be compatible with *your country's* CID, though) and have Caller ID active, you could make your modem connect to the Internet when it sees an incoming call from your mobile number.

by LjL
(DON'T USE THE FOLLOWING [GUESS WHY]: ljlspam@libero.it)

Security Suggestion

Anonymous's picture

Talking about the security of the above suggested system, I've just had an ideea after reading the article. How about configuring procmail so that it will only accept and pass on shell commands from a particular e-mail address (such as your remote one), instead parsing and accepting commands from any e-mail address. Or, how about changing the Perl script to send the replies to the shell commands only to a certain address (again, the remote admin address), or both of these solutions in the same time?

That should add some extra security, in the sense that it will make it more difficult for people to just send in an e-mail with the commands in the subject/header.

Re: Security Suggestion

Anonymous's picture

Except for the fact that it's incredibly easy to forge e-mail addresses, so if you went to the trouble of finding out what message to send, it would be trivial to put the 'correct' e-mail address in to ensure the command was executed.

You'd have to do something more complicated, like having some secret encrypted authorisation text in the message, a digital signature, etc, etc.

Re: Security Suggestion

Anonymous's picture

ya... thats right, also smtp address specifications can be added otherwise anybody can create a similar email adress and can send junk commands ...chahal

Re: Security Suggestion

Anonymous's picture

Unfortunately, source mail adresses can be easily spoofed. I think the encryption should yield

better results.

Re: E-mail as a System Console. Part I

Anonymous's picture

There is an application I've written which is similiar to the one proposed. I call it SMSTerm. Only that it works over SMS. So, you can do it all by using a cell phone. It uses the ICQ protocol for sending/receiving the SMS. Its in use for quite a few months now. I dont have a webpage or anything for it, since I'm in my final year of my engineering, and I dont have the time to put anything up. The source is under the GPL. You can view the project record at:


I wanted to do this when I wanted to manage a few servers at college while in class. :)

SMS is very cheap here (India) and there is considerable proliferation of GSM phones in the world. The only people missing out are in the US.

SMSTerm is in version 0.6 now. Additional features were added based on user demand.

I never thought it'd be that widely used. And, to see linuxjournal talking about a similiar thing is kinda sweet. :)