E-mail as a System Console, Part II
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.
In Part I of this article, I described the impetus for this project, devising a way to remotely access my home system so I could control internet connection times. Now let's get into what this system involves.
Fetchmail is one of those handy tools that makes using an operating system like Linux so much fun. It's easy to configure, has lots of functionality, and it does what you want, when you want, without much complaining. You can run it from cron or from the command line. If life could only be so easy.
For the e-mail console, you use fetchmail to retrieve e-mail from your ISP. This means you have to switch your current e-mail client from using POP/IMAP to picking up e-mail locally. Why do you have to do this? Well, when the MDA on your system wants to send e-mail to your account, it first checks to see if a file named .forward is in your home folder. If it is, all your mail is forwarded to the e-mail address in the .forward file. But wait! We don't want that to happen. What we want is the e-mail to be sent to procmail for processing. You'll learn how to do this in the next section. For now, remember the .forward file is the key.
Configuring fetchmail is a breeze. All you need to do is create a .fetchmailrc file in your home folder. You can read the man page for fetchmail and write this file yourself, or you can use fetchmailconf and generate the .fetchmailrc file. I wrote my original configuration file by hand, but the fetchmailconf application is a much faster way to get things going.
Here's a screenshot where I'm adding a new remote e-mail server.
Here's a screenshot where I'm setting up the server protocol and adding a new e-mail account.
Finally, here's a screenshot where I'm configuring the e-mail account password and setting up the processing options.
Once fetchmail is configured and working, you can run it from the command line or via cron.
This screen shows that fetchmail got a single e-mail from my ISP and then flushed (removed) it from my ISP. When you want to automate the fetchmail process, use cron to schedule a fetchmail call and make sure you use the silent (-s) command-line parameter; otherwise, you'll be getting lots of messages from cron each time fetchmail is run.
In order to make the e-mail console work, you must run fetchmail at regular intervals. Cron is usually a good way to go about doing this. Here's a sample crontab entry:
0,15,30,45 * * * * /usr/bin/fetchmail
Here's where it really starts to gets interesting. Procmail is the tool that makes the e-mail console possible. It scans a text file (your e-mail file, which is one giant file when it comes from your MDA) looking for patterns you specify, and then it performs some kind of action that you specify on a particular e-mail within the file. You see, procmail understands how to read this giant e-mail file and can perform an action either on the text itself or an action in general. For instance, you might have procmail scan incoming e-mail, and for each subject line have it execute a text-to-speech program so it reads each subject to you when new e-mail arrives. Kind of cool, right?
Our use of procmail involves scanning the subject lines of each e-mail looking for a given pattern that indicates the body of the e-mail holds a command sequence to be executed and the output captured and sent back to the sender of the e-mail. You also could have procmail react to the sender's e-mail address, but this is not as flexible. There are better ways to lock things down, as you will see in a while. So the big question you should have now is, "How do I tell procmail to scan my e-mail and do something?" Easy! You create a recipe for procmail.
Webinar: 8 Signs You’re Beyond Cron
On Demand NOW
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.View Now!
- When Official Debian Support Ends, Who Will Save You?
- Ubuntu Ditches Upstart
- Video On Demand: 8 Signs You're Beyond Cron
- "No Reboot" Kernel Patching - And Why You Should Care
- May 2015 Issue of Linux Journal: Cool Projects
- DevOps: Better Than the Sum of Its Parts
- Picking Out the Nouns
- Return of the Mac
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites