Autoresponder without Sendmail: Procmail and Mutt

Mutt is a Mail-User-Agent, but it supports the smtp- pop*- and IMAP*-protocols and can be run in batch-mode, meaning non-interactively (a “MTA”, you might say). Although Mutt can fetch mail from a remote server and supports all the current protocols, I prefer fetchmail for this job.

A procmail-rule which automatically sends the content of a text-file to the sender of an incoming mail, could look like this:

Code:

# Unencrypted mail
:0 
* !^Content-Type: multipart/(encrypted|signed).*
* !^X-Loop: .*admin@remainder_of_your_address.*
* !^Subject: Re:.*
* !^FROM_DAEMON
{
  :0H
  |/usr/bin/mutt "`formail -xFrom:`" -s "`formail -xSubject:`" -i /[path_to]/info.txt -e "my_hdr X-Loop: admin@[remainder_of_your_address]" 
  :0c
  Mail_dump/nocrypt
}

I like to keep a copy of the incoming mail in a folder “nocrypt”, but this second action is not necessary for the auto-responder to function.

The first action in the procmail-recipe, above, calls mutt and adds some command-line options:
`formail -xFrom`

put the From-address from the received mail directly behind the call to the mutt-executable

-i [anything that serves as upper mail-body]

With the -i option to mutt, you insert the content of the given file on top of the outgoing mail. As mutt receives from procmail the original mail-body, you can be quite sure that the recipient of your automatic mail can identify the message that they had sent to you to provoke the auto-response.
Maybe terminate the text-file with a line like: “Here follows the text of your original mail:” (or don't, if your requirements are different)

-e "my_hdr X-Loop: admin@[your domain]"

Add a header “X-Loop” to the outgoing mail. The value can be checked in any other (or the same) rule, to avoid your own messages being filtered. The value of the header-field can be quite anything, but you should stick to your decision, once you chose the content of this header, if you want to make this work flawlessly in the future.

-s `formail -xSubject:`

Formail finds the subject-line from the received mail and puts it here, after the -s option to mutt. This way, the outgoing mail should have the same subject as the original incoming message. There is a serious pitfall to avoid with this call to formail. Read the remainder of this blog-post to find out, how.

1. Does this way of using “give thought to something” in a phrase sound English?
2. What if the subject of the original, incoming mail contains spaces?

Read once again the command which is executed in the Procmail-recipe, above. It contains three named parameters : -i, -e and -s with their respective values. The very first argument to Mutt is just an email-address. In fact, Mutt considers any parameter which is not preceded with an option-indicator an email-address and creates 1 new mail for each of these parameters.
Now, if after the option “-s” some discrete words are listed like in “This is just an ordinary mail-subject”, Mutt composes the subject of the new outgoing mail as Subject: This and will address one mail to the address in the first argument, but also to 5 more invalid addresses, derived from “is”, “just”, “an”, “ordinary” and “mail-subject”. Bummer!

How the imaginary addresses appear in the To-header of the autoresponder-mail depends a little on your network-configuration but this is not important. Interesting rubbish remains rubbish and although the intended addressee of your message will receive a mail, its subject line will be truncated to just “This”. Not cool.

You must do something with the spaces in the subject. I guess, you can mask them with a backslash, I have tried to just replace these spaces by an underscore, because further consideration of what could be interpreted how by whom starts to give me a headache.

But it appears to be best to just use quotes around the system-calls to formail.

In conclusion, the call to mutt in the recipe had to be composed like this (same as above):

Code:

 |/usr/bin/mutt "`formail -xFrom:`" -s "`formail -xSubject:`" -i /[path_to]/info.txt -e "my_hdr X-Loop: admin@[remainder_of_your_address]"

As nice as this autoresponder may be, I do not use it any more. The idea was not completely dumb.., I think:
Inform all those who send me unencrypted and/or unsigned mail that their messages will not be answered, before I remember to check my bucket for such mail and only if I deem it worth the effort.
In reality, such an automatic mail does not make much sense. Most of those who receive it either do not comprehend a word or they ignore it anyway. Those who care respect my attitude since I told them.

Find your own uses, or rather: Could this filter facilitate anything?