In this article, I'll describe how to configure procmail using The Dotfile Generator (TDG for short). This will include:
Figure 1 |
Figure 2 |
The first category of backup is to back up all incoming mail. The code, which must be generated to the procmailrc file for this, will be written as the very first line. This is to avoid that any errors in the generated procmail file will throw away any of your mails. This sort of backup is only a good idea when you at first start using the generated procmail file. The main drawback is that all incoming mail is saved in one file, and this file may become huge very fast.
The second method is to backup all incoming mail, which are delivered by procmail. This may be a good idea to use, to verify that mail are sorted into the right places.
The third method is to backup all mail, which makes it to your incoming mailbox. This mail are often mails, which do not come from a mailing list, and which are not junk mail to thrown away.
In the first method, you have to specify the full filename. This is because this method has to be 100% full prof. In the next two methods you may build the file names from the current date and time. This makes it possible to save this sort of mail to folders, for the current year/month/week etc. E.g. a folder called backup-delivered-1997-July
As an additional feature, you may keep the files as gziped files.
The backup of delivered mail may be specified for each individual recipe, or for all recipes at once. (see figure 4 check box 9) To learn how to use the FillOut elements, which configures the file to save to, please see the Dotfile Generator article in Linux Journal.
Procmail will finish testing recipes when one is matched, unless a flag is set to tell it, that this recipe should not stop the deliverment (see figure 4 check box 8). This means that the order of the recipes are important, since only the first recipe, which match will process the letter.
If none of the recipes are fulfilled, or if the ones which are fulfills have check box 8 in figure 4 set, the letter is delivered to the incoming mailbox as if the procmail filter haven't been there at all.
You configure the recipes on the page called ``Recipes''. This page can be seen in figure 4.
What you see here is an ExtEntry. An ExtEntry is a widget, which repeats it elements as many times as necessary (just like a list box repeats the labels.) All what you see on this page, is one single recipe. To see a new recipe, you have to scroll the outer scroll bar (1). To add a new recipe, you have to press the button below the scroll bar.
As described above, a recipe is a set of conditions. This set is also represented with an ExtEntry (2). To scroll to another condition in a recipe, you have to use scroll bar (2), and to add a new condition, you have to use the button below scroll bar (2).
You may give each recipe a unique name, which will make it easier to find a given recipe. This name will also be written to the file with mail delivered by recipes (method 2 above), so you can see which recipe matched the actual letter. To give a recipe a name, use entry (3). At the right side of the entry, a button labeled Idx is located. This is a quick index to the outer ExtEntry (i.e. the recipes). If you press this button a list box will drop down, where you may select one of the recipes to scroll to, by its name.
From [email protected] Tue Jan 28 16:30:46 1997 Date: Tue, 28 Jan 1997 10:06:28 -0500 (EST) From: Rick Troxel <[email protected]> Subject: Re: Lynx as an external viewer for pine In-reply-to: <[email protected]> To: procmail mailing list <[email protected]> Cc: "Robin S. Socha" <[email protected]>The very first line of the letter is special. This line has been written by the program sending the letter (often called sendmail). This header field is often always the same for a given mailing list, so to sort mail from a mailing list, it might be a good idea to read the letter with an ordinary file reader (NOT a mail reader, as it will seldom show this line). And copy this information to the pattern field (figure 4, label (6) ). As the element to match, you have to select Sendmail from in entry (5).
Three special macros exists in procmail. These may be used, when matching header fields:
There is a lot of header fields to chose between in the pull down menu (5), but if the one you wish to select isn't located there, you may type it yourself.
The check box (4) may be used to negate the condition, i.e. the pattern shall not match to fulfill the condition.
One common pitfall is to forget to match everything at the start of the line. I.E. If you wish to set up a regular expression for the From: field above, it is not enough to give the pattern: [email protected], since this is not at the start of the line, you have to tell procmail that every mail messages, which includes the text [email protected] is to be handled, I.E. insert .* in front of the email address.
Procmail will consider the condition fulfilled if the exit code from the program is 0 and not otherwise. This behavior may be changed with the check button (4) in figure 4.
On this page you will find one custom-made filter: Remove signatures. With this filter, you may specify a signature for each email address. If the text you specify is found (exactly!) it will be removed from the letter. My intention is that more custom-made filters will be added, as users send me their ideas and filters.
As an example, you may remove the header with the command cat - >> /dev/null, or add a message to the body of a message with the command echo This letter has been resent to you, by my procmail filter!; cat -
If only the filter actions is selected, the filter will change the letter permanently, i.e. the changes will have effect on the subsequent recipes (even on the delivered letter, if no recipe match!) This may be useful if you e.g. uses a mail reader, which does not support mime, and you have a filter, which can convert mime encoded text to 7 bit ascii.
If however one of the other actions are enabled, the changes will only have effect within this recipe!
The reply is only sent, if the letter does not come from a daemon, to avoid that you sent a reply to every message on a mailing list.
Email addresses may be given in three ways:
Finally, you may pipe the header field though a command you specify yourself. This command may read the value of the header field on standard input, and write to standard output.
Should something go wrong, you may turn on extended diagnostic, this will write additional lines to the log file, which lets you see what it does. To debug this, you have to read both the log file and the procmail file.
If you use the log abstract options, you will find the program mailstat very useful. This will tell you how many letters have been delivered where. One line in the output from the mailstat programs is fake, and that is the line, which says: /bin/false. This line is due to the way that the generated code look. When you wish to throw away a letter, in a way so you can explicit see that is has been dumped, you should deliver it to the file called /dev/null. Please note that you can only use the mailstat program, if extended diagnostic is turned off.
"|IFS=' ' &&exec /usr/local/bin/procmail -f-||exit 75 #YOUR_USERNAME"With the correct pathname for procmail, and your email address replaced with YOUR_USERNAME
Here's a few link, which you may find interesting: