2001-01-03-05:32:35 Kumar Rajneesh Ranjan:
We are receiving some Unwanted mails which we want to block
Start by doing some testing. Create a test account, or use an
account whose email receipt isn't so important to you, and create a
file named ".procmailrc" in its home directory. See the examples in
procmailex(5). Start by trying to write a recipe to file the select
messages into a separate folder. Once you've got that working to the
point where you're confident in it, you have some choices; you can
adjust the recipe to deliver into the folder /dev/null, which will
discard the message; and/or you can install it into /etc/procmailrc
to make it take effect for all users of the system whose email is
delivered using procmail. As a separate decision, if you don't
already have things arranged this way, you can configure most Mail
Transport Agents to use procmail as a local delivery agent for all
local email deliveries. That'll make /etc/procmailrc take effect for
all users, rather than just those who choose to call procmail from
their ~/.forward files.
A couple of pieces of advice re writing filtering recipes.
- I strongly recommend debugging with a test acct, lest you
inadvertently lose email you care about.
- It's amazingly easy to write a recipe that looks good, but in
practice ends up matching things you don't want it to; seriously
consider never ever writing a recipe to /dev/null, always file
into a separate folder, and if necessary set up additional
processes to archive or automatically delete the messages in that
folder. Maildir format folders are often easier for scripts to
manipulate.
- Check out the logging features of procmail. When debugging my
procmailrc, I un-comment these defines that I keep at the top of
the file:
#LOGFILE=$HOME/.procmail-log
#VERBOSE=on
#LOGABSTRACT=all
It natters way too much to leave enabled at all times, but it's
great for debugging. Any time you write a recipe that's not a
trivially-edited cut-n-paste copy of a known-good, tested recipe,
turn on the debugging and examine it closely. Consider doing that
even for such cut-n-paste copies; it's astonishingly easy to make
trivial-seeming typos that cause a recipe to behave differently
from how you'd like.
Users are also sending some mails which we want to block
That turns out to be amazingly much harder, and much more
MTA-specific. Thanks in large part to procmail itself, the idea of
replacing the "local delivery agent", the program that delivers all
email messages for local users, is widely recognized, and all major
Mail Transport Agents support it very easily. However, a filtering
Local Delivery Agent like procmail isn't positioned to examing
outgoing traffic. Doing that requires a _different_ hook in the Mail
Transport Agent, and there are no standards. People have taken
advantage of qmail's modular architecture to interpose filtering;
sendmail has recently gotten a filtering interface; and so has
Postfix. Each is very, very different. Note that "outbound" is not,
for most Mail Transport Agents, a distinct case from "incoming" or
"relay" traffic; a filtering hook that can get at outbound messages
typically scrutinizes every message that passes through the MTA in
any direction.
One further note: the popular filtering Local Delivery Agents
procmail and maildrop can deliver such superb performance doing
their deliveries that the filtering can come essentially for
free. This is due to their _replacing_ an existing component of
any standard Mail Transport Agent, the Local Delivery Agent. By
contrast, performing filtering on all messages passing through
the MTA will almost invariably require significant additional
processing; expect to see a substantial performance hit, a factor of
two or more, for using such filtering facilities.
-Bennett
pgpsHKIVqZCO7.pgp
Description: PGP signature