[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cobalt-users] Re:How to Forward email to /dev/null



At 1:41 PM -0400 7/17/02, Bill Gunning is rumored to have typed:

> Can this be done using the GUI or with
> a .forward file? Or do I need to get a
> procmailrc file running?

   "Get(ting) a procmailrc file running" (and by the way, if it's in a user's
home directory, it's .procmailrc - only the systemwide /etc/procmailrc goes
without the leading dot) isn't exactly rocket science, since the Cobalts use
procmail as the local delivery agent by default. Using /bin/vacation, as
suggested by Tim, uses up yet-another-unnecessary-series-of-process, and
isn't the solution _I'd_ use, although I suppose as a kludge it'll work. If I
were going to send a long rejection message, I'd use procmail instead of
vacation, since it's MUCH more flexible.

   But vacation _or_ a procmail solution will give you major headaches down
the road, since the autoresponder will be responding to spam messages, which
will bounce, which will loop, which means you have to have loop protection,
which means...which means...which means...

   I would suggest you at least consider something COMPLETELY different. The
first thing this requires is that you have FEATURE(blacklist_recipients) set
up in your redhat.mc or cobalt.mc file (search the archives for a long post
by yours truly on how to create new sendmail.cf files, and see sendmail.org
for information on all the cool things FEATURE(blacklist_recipients) lets you
do).

   Add this line to your /etc/mail/access file, being careful to place it
BELOW the "# Put custom additions below (Do not change/remove this line)."
line (or you WILL lose your changes):

oldaddress@xxxxxxxxxxxxx	580 Resend to newaddress@xxxxxxxxxxxxx please

   Note the single <TAB> between the address and the error, not spaces. Note
also this MUST be a 500-level error, or machines will continue to attempt
delivery. And naturally you can use any error text you choose (within reason,
of course) to explain the change.

   Humans will be able to read the error message, spam will just get
rejected, NO extra processes will run on your machine, and you can't possibly
get into a mail loop since the mail will be rejected immediately during the
SMTP transaction. To see an example, feel free to send mail to
old.time.radio@xxxxxxxxxx (an old mailing list address); but note that I'm so
paranoid about automated spam harvesters, I don't even include the "@" in the
error message...

         Charlie