Invoking Procmail from Sendmail
and Procmail Spam filtering

Two popular set of scripts that can be used with procmail are spam bouncer and junkfilter. Both contain a lot of information on how to use it for mail filtering. Scamassassin also can be looked at but in latest version it is way too complex. 

NEWS CONTENTS

• 190404 : Procmail Tutorial by Jim Dennis ( Procmail Tutorial by Jim Dennis, )
• 190404 : procmailrules to filter out identifyable spam ( procmailrules to filter out identifyable spam, )
• 190404 : Simple header rules : ( )
• 190404 : OReilly Network Filtering Spam with Procmail [Jan. 10, 2002] ( O'Reilly Network Filtering Spam with Procmail [Jan. 10, 2002], )
• 190404 : http://junkfilter.zer0.org/ ( http://junkfilter.zer0.org/, )
• 190404 : The SpamBouncer a Procmail-Based Spam Filter ( The SpamBouncer a Procmail-Based Spam Filter, )

Old News ;-)

Procmail Tutorial by Jim Dennis

You could forward your mail through any arbitrary program with a .forward that consisted of a line like:

    "|$HOME/bin/your.program"

Note the quotes and the "pipe" character. They are required.

Now -- rather than saddling you with all details for how "your.program" would have to work -- what format sendmail would pass information to you, how you would return values to sendmail, how you'd handle file locking (in case more mail came in while you were processing the last one, etc) -- we'll move along to procmail specifically.

What I've discussed so far is the general information that applies to all sendmail-compatible MTA/MDA's.

One note that is well worth making is that although sendmail is designed and often run as an integrated transport and delivery, it's possible to configure a system to use procmail as the delivery agent (most of the popular Linux distributions default to this configuration, including Slackware, Red Hat, and Caldera).

In this scenario sendmail passes local mail to procmail. This makes things marginally easier as we'll soon see.

Assuming that your ISP is not so configured, you must create a .forward file to get sendmail to pass each incoming mail to procmai.

Here's the canonical example, pasted right out of the man pages:

    "|IFS=' '&&exec /usr/local/bin/procmail -f-||exit 75 #YOUR_USERNAME"

This seems awfully complicated compared to my earlier example. That's because my example was flawed for simplicity's sake.

What this mess means to sendmail (paraphrasing into English) is:

Pipe the mail to the following command(s):

Set the "inter-field seperator" (IFS) to a space, and -- if that went O.K. (&&) execute the program named "/usr/local/bin/procmail"

(yours may need to be different -- someone at primenet should tell you where their copy of procmail is installed, or you can try the command which procmail to see if it's on the patch or locate procmail if they are maintaining a file locator database).

The procmail program is being passed a set of switches: "-f-" which tells it to "update timestamp in the leading the 'From' line in the header"

(this last bit is rather obscure and has to do with how messages are normally stored in your "incoming" or mail file or "spool" as we Unix hacks like to call it).

The next part of this .forward command is the Bourne shell's "||" operator which is basically a continuation from the "and" (&&) operator that we used before. It says "or" (if that command didn't work -- i.e. it returned any error) than "exit" (stop processing) and return an error number 75 (which we presume is meaningful to sendmail -- the program that called this command).

The last part of this .forward expression is a comment which, according to the man pages,

is not actually a parameter that is required by proc- mail, in fact, it will be discarded by sh before procmail ever sees it; it is however a necessary kludge against overoptimising sendmail programs:

(quoting from it)

You should just change the phrase YOUR_NAME to your login name on that system.

This complicated line can be just pasted into most .forward files, minimally edited and forgotten.

If you did this and nothing else your mail would basically be unaffected. procmail would just append new messages into your normal spool file.

If your ISP uses procmail as its local delivery agent then you can skip the whole part of about using the .forward file -- or you can use it anyway.

In either event the next step to automating your mail handling is to create a .procmailrc file in your home directory. You could actually call this file anything you wanted -- but then you'd have to slip the name explicitly into the .forward file (right before the "||" operator). If you use .procmailrc than procmail will default to using it.

Now we can get to a specific example. So far, all we've talked about it how everything gets routed to procmail -- which mostly involves sendmail and the Bourne shell's syntax. Almost all sendmails are configured to use /bin/sh (the Bourne shell) to interpret alias and .forward "pipes."

procmailrules to filter out identifyable spam

Simple header rules :

A number of header things really identify spam very easily. These are sure signs of mail generated by spamming tools :

:0
* ^X-Advertisement:
spam

:0
* ^X-Advertisment:
spam

:0
* ^Message-ID: <>
spam

:0
* ^Received: from --- unknown host ---
spam

:0
* ^X-Mailer: RM-Super
* REMOVELIST:
spam

The next ones are a bit trickyer. They work by the idea that I don't have an account on sites used in the To: line of a lot of spam. But I did have to revise this as I sometimes recieve mail also aimed at an account there.

:0
* ^To:.*@(mail-response|msn|aol|public|hotmail|webavenues|netcom|ix.netcom)\.com
* !^(To|Cc):.*(koos|kh)@
spam

:0
* ^To:.*@(mts|usa)\.net
* !^(To|Cc):.*(koos|kh)@
spam

Including ofcourse the by now famous '[email protected]'. I pity whoever registered public.com. The check for mail not to 'koos@' is to make sure it's not by accident mail for a number of people including an account on one of those sites *and* me. That's valid mail.

The next set is 'famous spam relays'. The choice of addresses is purely from my own experience.

:0
* ^Received: from .*(mail.mymail.net|tsf-industries|spamrelay|flash.net|freemanchester.com|ultramax.net)
spam

O'Reilly Network Filtering Spam with Procmail [Jan. 10, 2002] -- into to Junkfilter and Spambouser

In the last article, we installed the procmail utility and generated a few basic recipes. This week, let's start by looking at procmail's built-in logging mechanism. We'll then take a look at some other available resources that build on procmail's capabilities.

On your FreeBSD system, there is a utility called mailstats that gives you statistics on how many messages were handled by the sendmail program

... ... ...

This site has an excellent list of resources that deal with procmail, including spam resources.

This site is a goldmine of procmail FAQs, tips, and resources, and is well worth bookmarking for future reference.

both of which are in the FreeBSD ports collection. This makes their installation painless. You'll find, though, it will take some trial and error on your part to tweak any spam filter to suit your needs. Also, no spam filter can be 100% accurate, as there will always be legitimate users that have email accounts with blocked domains and spammers are always trying to find new ways to bypass spam filters.

http://junkfilter.zer0.org/ junkfilter is copyright 1997-2002 Gregory Sutter.

junkfilter is a procmail -based filter system for electronic mail. Procmail is a popular and powerful mail-processing program available for Unix systems. junkfilter filters sex spam, MLM schemes, and all other types of unsolicited commercial e-mail (UCE). End spam -- filter it!

The SpamBouncer a Procmail-Based Spam Filter

The SpamBouncer is a set of procmail recipes, or instructions, which search the headers and text of your incoming email to see if it meets one or more of the following conditions:

• Originates from an email address known to belong to a spammer.
• Originates from known spam source sites, domains or hosts -- internet sites which exist solely or primarily to spam or provide services to spammers.
• Originates from irresponsible, or rogue, Internet Service Providers (ISPs), who permit spamming from their sites and fail to take appropriate action against spammers.
• Was sent using a bulk email program whose only or primary purpose is to send large quantities of junk email.
• Contains headers which match the SpamBouncer's profile of definite or probable spam.
• Contains body text strings which match the SpamBouncer's profile of probable spam.
• Contains body text strings which match the SpamBouncer's profile of a particular virus or class of viruses.

The SpamBouncer sorts suspected spam into three categories -- email sent by a virus, email from known spam sources which is definitely spam, and email which is probably spam, but might also be legitimate. It then tags each email with appropriate headers for the spam classification, and responds according to the parameters you have set.

The FreeBSD Diary -- Setting up Spam Bouncer

Alcor On-Line Help catching spam with procmail

DevX: Procmail 'Passthrough' Partners for Powerful E-mail Filtering(Dec 20, 2001)

Linux Gazette: Stopping Spam on Your Linux Box (May 12, 2001)

LinuxWorld: Ask the Geek: Fight spam with procmail(Mar 02, 2001)

Your first e-mail filter
We rely on procmail for automating e-mail traffic. We'll focus on it's installation and use (for an overview of the procmail utility (see Resources below).

First, verify that procmail is installed on your host. Most ISPs that provide shell access make it available as /usr/local/bin/procmail/var/bin/procmail, or some local variation. Corporate networks are less likely to have procmail, so don't be surprised if you can't find it on your host. The directions available at the procmail home page are easy, so you or your sysadmin will have it up and running in short order.

Once you've confirmed that procmail is available as a Unix executable, take these steps:

1. Create the file $HOME/.procmailrc with contents:

   	VERBOSE=on
   	MAILDIR=$HOME/mail
   	PMDIR=$HOME/.procmail
   	LOGFILE=$PMDIR/log
   	INCLUDERC=$PMDIR/rc.personal
   

2. Create the file $HOME/.procmail/rc.personal with contents:

   	:0:
   	* ^Subject.*cable descrambler
   	discard

3. Create the file $HOME/.forward with contents:

   	"|IFS=' ' && exec /usr/local/bin/procmail -f || exit 75 #YOUR EMAIL NAME"
   

   This is the step that's likely to involve the most variation from one system to another. In the last item in the Resources list below, we list the .forward commands we've found to work best under a variety of operating systems.

4. Set necessary permissions with the commands:

   	chmod 644 $HOME/.forward
   	chmod a+x $HOME

5. Test the filter by typing the four lines:

   	sendmail YOUR_EMAIL_ADDRESS
   	Subject: send us money
   	blah, blah

6. And then the four lines:

   	sendmail YOUR_EMAIL_ADDRESS
   	Subject: send us money for our cable descrambler
   	blah, blah

What you should see now is that you have one new mail message, with the subject line, "send us money." You'll also have a new file, $HOME/mail/discard, that holds the "send us money for our cable descrambler" message.

You're in business. You now have the means to protect yourself from messages you don't want to see.

Variations on a theme
There are many steps you'll want to take to improve your filter. You can add a second rule, and your ruleset becomes:

	:0:
	* ^Subject.*cable descrambler
	discard

	:0:
	* ^Subject.*adults only
	discard

You can filter out messages from sites notorious for their junk:

	:0:
	* ^From: [email protected]
	discard

or from suspicious-looking people:	
	:0:
	* ^From anonymous
	discard

	:0:
	* ^From bulk
	discard   

You'll probably want to throw away the electronic equivalent of "Deliver to Resident" messages,

	:0:
	* ^To:.*public.com   
	discard

as well as anything courteous enough to announce itself as an unsolicited advertisement:

	:0:
	* ^X-Advert
	discard

Recommended Links

Softpanorama Recommended

Top articles

Sites

• Procmail Homepage

• Procmail Tutorial by Jim Dennis

• a searchable archive of the procmail mailing list

• Era Eriksson's Procmail Mini-FAQ
• Peter Hartzler's SmartList FAQ
• Jari Aalto's Procmail resources
• Nancy McGough's Procmail Quick Start page at it's primary server or from a mirror.
• Timo Salmi's procmail tips and recipes
• Philip's TODO list
  This includes information on obtaining snapshots of the current source trees for procmail and SmartList.
• the untarred source tree for the stable version of procmail
• the untarred source tree for the stable version of SmartList

Tutorials

Configuring Procmail as a Sendmail rule-invoked mailer

This is a basic tutorial on how to invoke procmail from within a sendmail ruleset (not as Mlocal, but actually invoked during mail processing, with the express intention of having sendmail continue to process a message which procmail may have changed in some fashion).

John Hardin has a writeup on configuring Procmail within a sendmail gateway, which is a similar process.

Let me start with a few disclaimers - these are rough notes from when I performed such a test on a Sendmail 8.10.x system (i.e. some time ago) with the mere intent of learning how to do it myself so that users who insist on repeatedly asking for this info on the procmail list can be directed to a page laying out the details for them, even though it is really SENDMAIL trickery and the procmail manpage ('man procmail') already provides the basic framework. I do not utilize this approach - I personally have no need for invoking procmail from within sendmail rulesets, and certainly not enough of one to justify the additional processing overhead which it involves. I WILL NOT answer private inquiries for assistance, unless they accompany a service contract and an appropriatley negotiated retainer (US$ only please). I am dead serious. I'm not in the business of taking blame or becoming someone's tecnical crutch or emergency repairman when they take it upon themselves to diddle with the internal mechanisms of tools which they don't fully comprehend.

If you don't maintain your sendmail config using .M4 files, then shame on you. If you don't know about the .M4 config files, and the "make" process for them, then you want to get acquainted with that before proceeding here. It is enough that I'm spelling out this hack, but I am NOT going to re-document sendmail too.

Let me give you clear warning: screwing with your procmail config can cause mail to JUST DISSAPPEAR. Gone. Poof. The only trace you'll have might be mention of it in your system logs. Experienced techs know that the best way to test sendmail configurations is in a sandbox - on a server set aside specifically for performing those tests. Well, at least not a server used for regular mail processing - I use a security monitoring host which isn't used in any fashion for email - it isn't an MX, and there are no users on it (or a web server, etc) to be generating messages. If you do development changes to a live mail server, you won't find any sympathy with me if something goes sour on you.

Your application of any information gained from this document is entirely at your own risk - there are many variables in play, not the least of which are your sendmail version and other sendmail configuration options you may have in effect.

Having said that, using procmail from within sendmail isn't really all that difficult - if you understand the sendmail config file syntax (having a copy of the ORA "Sendmail" book (or the ORA Bookshelf CD version) to reference would be a good idea).

Many people errantly use MAILER(`procmail') in their sendmail M4 config files when initially setting up sendmail to use procmail, when all they're trying to do is set up sendmail to use procmail as the LDA. For that, they need to use FEATURE(`local_procmail') - which sets the Mlocal properly. the MAILER definition has *NOTHING* to do with procmail as the LDA, and is unnecessary unless you're trying to invoke procmail from within sendmail rulesets.

In your config.mc you'd add MAILER(`procmail') on a line BEFORE MAILER(`smtp') (remember, the config is processed in reverse or something like that). Build the config.cf file, make any manual edits you might have to make, then (usually in ruleset 0, or "Sparse=0"), add something like the following (note that with the supplied .m4 file below, this is already done):

R$*	$: $>ProcmailHandler $1		# procmail filtering

I'm using the newer sendmail syntax for ruleset labelling - you can use names instead of just numerics. Now, somewhere else in the file - I typically do it down below, but in any event, you should be careful to ensure that it is BETWEEN rulesets or definitions, not dropped in the middle of one, add:

You may download this file as ProcmailHandler.m4.

divert(-1)
#
# Copyright (c) 2002 Professional Software Engineering.
#	All rights reserved.
#
# By using this file, you agree to hold the author and it's agents harmless.
#
# The rules provided herein are intended only to demonstrate the basic
# functionality of procmail as a sendmail rule-invoked mailer.
#
# 
#

ifelse(defn(`_ARG_'), `',
	ifdef(`PROCMAIL_MAILER_PATH',
		PROCMAIL_MAILER_PATH,
		`/usr/local/bin/procmail'),
	_ARG_))

divert(0)
VERSIONID(`$Id: procmailhandler.m4,v 8.12 2002/02/01 12:58:08 sbs Exp $')

MAILER(`procmail', PROCMAIL_MAILER_PATH)dnl

LOCAL_RULE_0
R$*	$: $>ProcmailHandler $1		# procmail filtering

LOCAL_RULESETS
SProcmailHandler
# Following three lines are from Adrezej Filip on comp.mail.sendmail 20030412
# This allows sendmail to ignore the hack when it processes newaliases
R$*	$: <${opMode}> $1
R<i>$*	$@ $1
R<$*>$*	$: $2

# parse for local users (single token, no domain)
# note that depending upon where you place the hook for this ruleset,
# this may occur before or after sendmail expands aliases which may
# resolve an apparent local delivery to a remote address - place your
# hook as you see fit.
R$- .procmail
	$@ $1
	# procmail has already looked at this
R$-
	$#procmail $@/etc/procmailrcs/outbound.rc $: $1 . procmail
	# invoke procmail

# parse for canonical domains
# (resolved domains will have a dot trailing the domain name)
R$* < @ $+ .procmail >
	$@ $1 < @ $2 . >
	# procmail has already looked at this.
R$* < @ $+ . >
	$#procmail $@/etc/procmailrcs/outbound.rc $: $1 < @ $2 .procmail >
	# invoke procmail

# parse for non-resolveable canonical domains
# (unresolved domains will NOT have a dot trailing the domain name)
R$* < @ $+ .xprocmail >
	$@ $1 < @ $2 >
	# procmail has already looked at this.
R$* < @ $+ >
	$#procmail $@/etc/procmailrcs/outbound.rc $: $1 < @ $2 .xprocmail >
	# invoke procmail

# other examples would include filtering for a specific user address or
# hostname/domain or inbound vs. outbound.  Handle more specific cases FIRST.

divert(0)

As with all sendmail rules, there is a TAB between the LHS and RHS, and if you continue a line, it should start with a TAB. The trailing dot in the above expressions is there because in my sendmail config (which other current sendmails should be very similar to) canonicalizes the address to include a trailing dot.

In your /etc/procmailrcs/outbound.rc, you'd have something like:

#
# This is a simple script intended to demonstrate sendmail rule-invoked
# procmail filtering.
#

DEFAULT=|
SHELL=/bin/sh
LOGFILE=/etc/procmailrcs/outbound.log
VERBOSE=ON

# grab the arguments from the commandline and put them into variables.
USER=$1
REC=$2

# copy *ALL* messages.  This is just an example.
:0c:
/etc/procmailrcs/outbound.copy

# rewrite certain message to include a trailing disclaimer
:0f
* USER ?? someusername
* ^From:.*someusername@host\.domain\.tld
| cat - /etc/procmailrcs/trailer.sig

# Pass along all other mail (or filtered messages)
:0
! -f "$@"

This file should have appropriate ownership and security settings (i.e. don't make it group or world writeable - and probably, you don't even want it readable by anyone other than owner).

Now, to explain. Mprocmail is the procmail mailer - it tells sendmail how to invoke procmail and what options to apply to it, etc. The specifics are uninmportant to the basic implementation - it is handled just like Mlocal or Mprog according to your config. In the standard MAILER definition, procmail is handed the rcfile, the sender address/username, and the recipient username/addresses(s). The rcfile above takes the two commandline options (things specified after the rcfile) and assigns them to variables which it can then use.

For EXAMPLE purposes only, we have VERBOSE logging on and are dumping to a logfile. You wouldn't want that enabled on a regular high-traffic mailspool. Also for EXAMPLE purposes, there is a rule which uses the 'c'opy flag to make a copy of the messages passing through this rc and store them to a mailbox file. Yup, instant copy of inbound and outbound message traffic (at the moment, the rcfile has no idea whether the message is inbound or outbound - that's a function of the sendmail ruleset you use to invoke it, and where you perform that invocation). Next in the example is something that checks whether the sending user is a specific username and the From: field contains their address (you might do either, but this is intended to catch LOCALLY generated messages where the user MIGHT change the From: field, or be using procmail to forward a message (which you might not want to append the disclaimer to). Anyway, the filter rule pipes through to cat which takes the original message and follows that with the signature text (in my test case, it is a truely obnoxious parody of the legal disclaimers some offices stuff on all of their outbound messages). Now, this was just a FILTER rule, so the (modified) message continues along to the next rule - as would any message which didn't meet the conditions to be filtered - that last rule (which you should recognize from the procmail manpage, 'cept for the omission of the '-oi') delivers the message to sendmail ensuring to set the -f (sender) address to the same address we received it from.

Yes, it is unfortunate that the invocation of mailers from sendmail doesn't allow them to simply be piped through, but in sendmail's mind, once it invoked the procmail mailer (Mprocmail), it was delivered, so for procmail to have sendmail continue processing it, it must invoke sendmail with the message.

Now, we've covered the back end, but I haven't yet explained the sendmail rules. I should preface this by saying that the specific rules you might choose to use from sendmail are your business, and are something you should follow up in a sendmail support forum (news:comp.mail.sendmail perhaps), as, with the exception of invoking procmail, they don't really pertain to procmail at all. That said:

We inserted the following rule into the parse ruleset:

R$*	$: $>ProcmailHandler $1		# procmail filtering

The LHS says "does this match ANYTHING?" If so, then the RHS gets processed, which says "Okay, then, call the ProcmailHandler ruleset with the argument we're parsing".

Elsewhere in the .cf, we introduced the ProcmailHandler ruleset (see above).

It is important to remember that the rules there are separate - although related - rules. On a call to the ProcmailHandler ruleset, ONE of these will take effect (or none will, if there is no match), and will return to the caller without invoking the other. It is for this reason that we check for the .procmail ones first within each pair (since the final rule above would gladly match most messages even if .procmail is already appended).

The first pair of rules operate on single token addresses: that being a local type address consisting of just a username. The second pair operate on canonically resolved addresses. Within each pair, the first one says "if we match an address with a .procmail at the end, then strip that .procmail bit out (this is what cleans up the rewritten address after procmail is invoked). The other rule says that if we have an address (presumed at this point to NOT have a trailing .procmail), then invoke our procmail mailer and also change the address (this is how we ensure that we don't execute procmail a second time when the message is re-introduced into sendmail).

It might help if you create a config file with the above rulesets, then execute:

sendmail -bt -ctesting.cf
> 3,0 someuser
> 3,0 someuser.procmail
> 3,0 [email protected]
> 3,0 [email protected]
> 3,0 someuser@bogusdomain
> 3,0 [email protected]

You should find that the non-.procmail versions end up parsing into a .procmail version and showing that the procmail mailer would have been called. If you parse the .procmail versions, you'll see that they get resolved down to a local or (E)SMTP delivery as appropriate, with the .procmail portion stripped out. Note that with the canonical domain stuff here, the domain.tld should actually be RESOLVEABLE - if you need to deal with unresolvable domains (why? Surely if you're dealing with a bogus domain, you'd at least locally resolve them in /etc/hosts, right?), you'll need to clone the second pair of rules and remove the trailing dot and tweak the .procmail bit to something slightly different (so that the original rule above doesn't add a dot where it isn't appropriate when rewriting). In the ruleset above (and in the .M4 file linked below), I've included this rule, but you really shouldn't need it.

Because of the broadness of the last expression, you'd want this AFTER the version which handles resolveable hosts ( the $+ would gladly match a hostname with a trailing dot). Specifically, you don't want a rewritten host like : somehost.domain.tld..procmail (note TWO dots). Go ahead, and move the last two rules up and run the address tests again and see what you get, then switch them back so that it isn't broken.

In any event, if the second rule (in any pair) matches, then we'll invoke the procmail mailer on this message and rewrite the recipient address to include the .procmail bit. The above address test will demonstrate this at work.

I've created a HACK (that's a real sendmail macro - just like FEATURE and MAILER) file for the above, which you can add to your sendmail config tree:

/usr/src/sendmail/cf/hack/ProcmailHandler.m4

Then add the following to your config.mc file AFTER your MAILER(`smtp') line:

HACK(`ProcmailHandler')dnl

This will add the MAILER(`procmail') and the necessary rules to your generated .cf file. You'll still need to verify the procmail path (which you can conveniently specify as a second parameter to the HACK macro above), and create the /etc/procmailrc/outbound.rc file and necessary filters, but otherwise, it should work.

Something to note is that in doing this, virtually every email passing through your sendmail will generate an extra process (procmail), plus additional processes beyond that (if procmail runs any shells or other programs in pursuit of the checks/filters), and another sendmail process if procmail actually filters the message rather than discarding it. The additional invocation of sendmail will carry with it the introduction of an additional Received: header as well, indicating the message was received from root@localhost.

procmail-on-gateway

Implementing procmail on a sendmail 8.8.8 and later gateway:
(Note: This is still undergoing testing and refinement)
$Id: procmail-on-gateway.txt,v 1.9 2002-01-12 16:41:00-08 jhardin Exp jhardin $
<[email protected]>
With help from Joshua Marshall <[email protected]>


1. Add the following delivery agent:

Mprocmail,      P=/usr/bin/procmail, F=DFMmShun, S=11/31, R=21/31, T=DNS/RFC822/X-Unix,
                A=procmail -m $h $g $u

   [TAB]---^



2. Add "procmail" to class P with this somewhere near the top
of your sendmail.cf (near where the other classes are being set up):

  CPprocmail



3. Add the following to ruleset 0, between the "handle virtual
users" and "short-circuit local delivery" stanzas:

# pipe through procmail for processing
R$*<@example.com>$*     $#procmail $@/etc/procmail/filter.rc $:$1<@example.com.procmail.>$2
R$*<@example.com.>$*    $#procmail $@/etc/procmail/filter.rc $:$1<@example.com.procmail.>$2
R$*<@$*.procmail.>$*    $1<@$2.>$3

   [TAB]-------------^

Vary the domain name and script name (/etc/procmail/filter.rc) for your needs.

If you are relaying mail for multiple domains, use the following instead:

R$*<@$=w>$*             $#procmail $@/etc/procmail/filter.rc $:$1<@$2.procmail.>$3
R$*<@$=w.>$*            $#procmail $@/etc/procmail/filter.rc $:$1<@$2.procmail.>$3
R$*<@$*.procmail.>$*    $1<@$2.>$3

   [TAB]-------------^



If you prefer to use sendmail .mc files, add this to your config.mc file:

LOCAL_CONFIG
CPprocmail

LOCAL_RULE_0
R$*<@$=w>$*             $#procmail $@/etc/procmail/filter.rc $:$1<@$2.procmail.>$3
R$*<@$=w.>$*            $#procmail $@/etc/procmail/filter.rc $:$1<@$2.procmail.>$3
R$*<@$*.procmail.>$*    $1<@$2.>$3

MAILER_DEFINITIONS
Mprocmail,      P=/usr/bin/procmail, F=DFMmShun, S=11/31, R=21/31, T=DNS/RFC822/X-Unix,
                A=procmail -m $h $g $u



4. Here is a sample filter.rc file - add your local configuration
   settings before using it:

################################################################
#
# procmail rules to filter mail on a gateway
#

LOGFILE=/var/log/procmail.log
NL="
"
LOGABSTRACT=no

# Configuration settings go here...
# See the discussion of what to put in /etc/procmailrc at
# http://www.impsec.org/email-tools/sanitizer-configuration.html
# /etc/procmailrc is the "master procmail script" for local
# delivery, this file is the "master procmail script" for relay
# The settings in one DO NOT affect the other.

POISONED_EXECUTABLES=/etc/procmail/poisoned

# etc... - you NEED to put configuration settings here.
# NB: DO NOT enable RECIPIENT notification on a relay...

# run the sanitizer
INCLUDERC=/etc/procmail/local-rules.procmail
INCLUDERC=/etc/procmail/html-trap.procmail

# send the mail on to the next relay
:0
! -oi -f "$@"

#
################################################################



5. If the next hop is a Microsoft Exchange Server, make sure that you
configure it so that it will accept mail addressed to its
fully-qualified domain name in addition to the simple domain name.
For example, if your domain is "example.com" and your Exchange Server is
running on the computer named "exchange", configure it to accept mail
addressed to "@exchange.example.com" as well as just "@example.com"

Recommended Papers

O'Reilly Network Filtering Spam with Procmail [Jan. 10, 2002] -- into to Junkfilter and Spambouser

In the last article, we installed the procmail utility and generated a few basic recipes. This week, let's start by looking at procmail's built-in logging mechanism. We'll then take a look at some other available resources that build on procmail's capabilities.

On your FreeBSD system, there is a utility called mailstats that gives you statistics on how many messages were handled by the sendmail program

... ... ...

This site has an excellent list of resources that deal with procmail, including spam resources.

This site is a goldmine of procmail FAQs, tips, and resources, and is well worth bookmarking for future reference.

both of which are in the FreeBSD ports collection. This makes their installation painless. You'll find, though, it will take some trial and error on your part to tweak any spam filter to suit your needs. Also, no spam filter can be 100% accurate, as there will always be legitimate users that have email accounts with blocked domains and spammers are always trying to find new ways to bypass spam filters.

The SpamBouncer a Procmail-Based Spam Filter

The SpamBouncer is a set of procmail recipes, or instructions, which search the headers and text of your incoming email to see if it meets one or more of the following conditions:

• Originates from an email address known to belong to a spammer.
• Originates from known spam source sites, domains or hosts -- internet sites which exist solely or primarily to spam or provide services to spammers.
• Originates from irresponsible, or rogue, Internet Service Providers (ISPs), who permit spamming from their sites and fail to take appropriate action against spammers.
• Was sent using a bulk email program whose only or primary purpose is to send large quantities of junk email.
• Contains headers which match the SpamBouncer's profile of definite or probable spam.
• Contains body text strings which match the SpamBouncer's profile of probable spam.
• Contains body text strings which match the SpamBouncer's profile of a particular virus or class of viruses.

The SpamBouncer sorts suspected spam into three categories -- email sent by a virus, email from known spam sources which is definitely spam, and email which is probably spam, but might also be legitimate. It then tags each email with appropriate headers for the spam classification, and responds according to the parameters you have set.

The FreeBSD Diary -- Setting up Spam Bouncer

Alcor On-Line Help catching spam with procmail

DevX: Procmail 'Passthrough' Partners for Powerful E-mail Filtering(Dec 20, 2001)

...

>I read somewhere that you can invoke procmail from within sendmail. How
>do I do that? Does that mean that some filtering can be done in
>sendmail?

Summarized from another recent thread - this will send all mail through
procmail.

Put this in your .mc file:

FEATURE(`mailertable')
MAILER(`procmail')

LOCAL_CONFIG
CP PROCMAIL

LOCAL_RULE_0
R$*				$: <> $1			mark all
R<> < @ $* > $*			$: < @ $1 > $2			skip route-addr
R<> $* < @ $* . PROCMAIL . >	$: $>3 $1 @ $2			already filtered
R<> $* < @ PROCMAIL . >		$: $1				already filtered
R<> $* < @ $* . >		$: <> $1 < @ $2 >		remove dot
R<> $* < @ $* >			$: $1 < @ $2 . PROCMAIL . >	send to procmail
R<> $*				$: $1 < @ PROCMAIL . >		send to procmail

And in your mailertable:

PROCMAIL   procmail:/etc/procmailrcs/some.rc
.PROCMAIL  procmail:/etc/procmailrcs/some.rc

See cf/README in the sendmail distribution, and the procmail man page,
for further details.

You may also want to use

MODIFY_MAILER_FLAGS(`PROCMAIL', `+m')

or for pre-8.10 sendmail

define(`PROCMAIL_MAILER_FLAGS', `SPhnu9m')

in your .mc file - this will improve performance by sending mail for
multiple recipients through a single invocation of procmail, but makes
address-based processing in the procmaillrc trickier.

--Per Hedeland
[email protected]

Discussion

On Fri, May 19, 2000 at 08:31:37AM -0400, Joe Borgia wrote:
> Anyone know of a way to block *.vbs, *.exe, *.com files in sendmail
> running
> on Solaris. It's sendmail.org's version of sendmail, but it's running on
> Solaris. Most
> of what I've seen here in this group talks about blocking on Linux boxes
> using procmail. Honestly, I don't know what procmail does, and I don't
> believe it's
> running on our sendmail server.

procmail is a MDA (mail delivery agent). It's task is to deliver your the incomming mail to the local users on your server.

Sendmail can use procmail or any other MDA. Run `grep Mlocal
/etc/sendmail.cf` to see what MDA is default in your setup.

All this software probably works just as well on Solaris as on linux. You can use the procmail-filters you refer to, or you can use
mailchecker (search on sourceforge.net). It's software written
specificly for sorting out dangerous mail-parts. (not well tested - prepare to work a little bit)

--
Ragnar KjЃшrstad

On Thu, 18 May 2000 21:52:20 +0100, A Pietro <[email protected]> wrote:
>How can I filter out email messages which have file attachments?
>
>Do I use something called procmail.rc -- I think this file has rules to
>filter spam?
>Do I look for a certain type of header?
>
If you have procmail installed, the following might help:

ftp://ftp.rubyriver.com/pub/jhardin/antispam/procmail-security.html

See also ftp://ftp.rubyriver.com/pub/jhardin/antispam/html-trap.procmail

There are many other ways to do something similiar.

--
Frank Hahn

A fool must now and then be right by chance.

In article <[email protected]> [email protected] (Sean
A. Walberg) writes:
>On this thread, how would one hack sendmail to use procmail in a
>non-local-delivery sense, ie passing all mail on a hub through
>procmail before it gets sent out or to the mail server? The man page
>for procmail requires that the domain be static, in which case it only
>works for incoming mail.

Well, it's just an example... - you could do something like this to send all mail through procmail (untested!):

FEATURE(`mailertable')
MAILER(`procmail')
...

LOCAL_CONFIG
CP PROCMAIL

LOCAL_RULE_0
R$* $: <> $1 mark all
R<> $* < @ $* . PROCMAIL . > $* $: $>3 $1 < @ $2 > $3 already filtered R<> $* < @ PROCMAIL . > $: $1 already filtered
R<> $* < @ $* > $* $: $1 < @ $2 . PROCMAIL . > $3 send to procmail R<> $* $: $1 < @ PROCMAIL . > send to procmail

And in mailertable:

PROCMAIL procmail:/etc/procmailrcs/some.rc
.PROCMAIL procmail:/etc/procmailrcs/some.rc

One un-nice thing about it is that the recipient address(es) will have .PROCMAIL (@PROCMAIL for unqualified addresses) appended while in the procmailrc, i.e. you need to take that into account if doing
address-based processing.

--Per Hedeland
[email protected]

In article <[email protected]>
"Sean A. Walberg" <[email protected]> writes:
>And I can see it in the queue. Now I push it out:
>[root@phoenix mqueue]# sendmail [email protected]
><[email protected]>... Host unknown (Name server:
>exchange.hsc.mb.ca..procmail.: non-recoverable error)
><[email protected]>... Host unknown (Name server: escape.ca..procmail.:
>non-recoverable error)

There is a bug in the rules I gave, resulting in the double dot before 'procmail'. Here's an updated version:

R$* $: <> $1 mark all
R<> $* < @ $* . PROCMAIL . > $* $: $>3 $1 < @ $2 > $3 already filtered R<> $* < @ PROCMAIL . > $: $1 already filtered
R<> $* < @ $* . > $* $: <> $1 < @ $2 > $3 remove dot R<> $* < @ $* > $* $: $1 < @ $2 . PROCMAIL . > $3 send to procmail R<> $* $: $1 < @ PROCMAIL . > send to procmail

However it seems you also don't have the mailertable working - test it:

sendmail -bt
> /map mailertable procmail
> /map mailertable .procmail

>Though what I don't understand why the address doesn't get rewritten,

It clearly does get rewritten, note the

Name server: exchange.hsc.mb.ca..procmail.: non-recoverable error

message. The error reports the original address though, as it should.

>when:
>
>> [root@phoenix mqueue]# sendmail -bt
>ADDRESS TEST MODE (ruleset 3 NOT automatically invoked)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>Enter <ruleset> <address>
>> 0 [email protected]

That isn't a proper test, you need

> 3,0 [email protected]

- without the pass through ruleset 3, it is effectively treated as if it were a simple username.

--Per Hedeland
[email protected]

Just to follow up on this, it's been working great for a couple of days now.

One thing to note is that multiple recipients seem to get expanded to one run through procmail per address. Not a big deal until you try to cram through a couple of thousand emails at once, ie a list. Once I upped the max files allowable all was well.

Once again, many thanks!

Sean

On Tue, 09 May 2000 01:19:59 GMT, [email protected] (Sean A. Walberg)
wrote:

>On 9 May 2000 00:36:58 GMT, [email protected] (Per Hedeland) wrote:
>
>>Grumble... When I wrote "untested", I was hoping to not having to bother
>>testing them...:-) Anyway, I'm not sure that's the cause of what you're
>>seeing, but there's another bug in the rules - also, trying to handle
>>"route-addrs" (<@foo,@bar:user@baz>) is futile, they won't work when
>>passed to procmail and back (and no-one uses them, and they're stripped
>>down by default in 8.10 anyway). So, yet another version:
>>
>>R$* $: <> $1 mark all
>>R<> < @ $* > $* $: < @ $1 > $2 skip route-addr
>>R<> $* < @ $* . PROCMAIL . > $: $>3 $1 @ $2 already filtered
>>R<> $* < @ PROCMAIL . > $: $1 already filtered
>>R<> $* < @ $* . > $: <> $1 < @ $2 > remove dot
>>R<> $* < @ $* > $: $1 < @ $2 . PROCMAIL . > send to procmail
>>R<> $* $: $1 < @ PROCMAIL . > send to procmail
>
>This seems to work for incoming mail, but I've yet to test it for
>outgoing. I'll follow up tomorrow when I can test it fully.
>
>I've already had a couple of people ask about some of my other queries
>regarding this topic, once I get it all working I'll write it up and
>post a URL so you shouldn't have to answer this again :)
>
>Thanks again,
>
>Sean
>
>---
>Sean Walberg <sean at ertw dot com> http://www.ertw.com
>Winnipeg Linux/Unix events http://linux.ertw.com

---
Sean Walberg <sean at ertw dot com> http://www.ertw.com
Winnipeg Linux/Unix events http://linux.ertw.com

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019