On Fri, 3 Sep 1999 17:00:14 -0400 (EDT), Chuck Mead
<chuck(_at_)moongroup(_dot_)com> wrote:
I have this procmailrc file running for user cgate:
There are some minor nits but I'll pick them in a moment.
There are two mailing lists we wanted to gate together so we used a
"dummy" account and this script... cgate is sub'd to both lists and
this hack is indeed working but I'd really like to improve it a bit
without breaking it in the process. Sadly... I haven't a clue where
to start (and yes I've read the doc's on formail, and man
procmailex, man procmail, etc. etc. but when I try something new it
breaks the script and as it is in operation I'd rather not).
A simple script like yours can easily be copied to a "sandbox" where
you can tweak it to your heart's content until you are confident your
fixes work, then just copy it back over the real thing when you're
done. (Version control and project management software are useful
tools if you find yourself doing this often.)
You might want to try your script (the sandbox version) on a few
sample messages and replace the calls to Sendmail with e.g. saving to
somewhere in /tmp so you don't have to wait for Sendmail to deliver
your (possibly faulty) test messages.
What I'd like to do is pass the original sender's From: address
going either way so that people will have a clue who sent the mail
if it happened to come from the gated list rather than from their
"local" list. As it is now both lists can only see a From: address
of cgate(_at_)moongroup(_dot_)com if it's passed through the gateway. It may
be that we have to convert it to an X-Sender: or something like
that to keep mail from bouncing from the lists but if somebody has
a recommendation I'm all ears.
Why override From: with your own From: line at all? The motivation for
the Sender: field is that you use it when you send something on
someone else's behalf. So I'd say you should just keep the original
From: field and put your cgate address in Sender: instead.
I'll appreciate any help greater than an RTFM... thanx!
RTFRFC :-)
... Oh, and those nits I wanted to pick:
SENDMAIL=/usr/sbin/sendmail
Allow me to quote from the Mini-FAQ:
Q: I want to strive for elegance and efficiency in my regular
expressions, and ultimately achieve Procmail guru status. What typical
newbie mistakes should I try to avoid?
A: Good girl/boy. Here's a partial list.
<...>
* On a related note, don't change Procmail's built-in ideas of the
values for the variables DEFAULT or SENDMAIL unless you are fairly
confident you know what you are doing. That goes doubly so for
ORGMAIL -- if you're changing it then you're probably going about
the problem the wrong way.
The blunt way to say this is, if the value of SENDMAIL is wrong, you
should recompile your Procmail rather than change SENDMAIL.
:0
* ^Reply-To:(_dot_)*c(_at_)lunar-penguin(_dot_)com
{
:0 c
| $FORMAIL -i "From: cgate(_at_)moongroup(_dot_)com" -i "Reply-To:
cgate(_at_)moongroup(_dot_)com "\
-a "X-Reply-To: $FROM"|\
$SENDMAIL -oi linuxCprogramming(_at_)listbot(_dot_)com
:0
/dev/null
}
Later on in the same section of the FAQ:
* You frequently see stacked recipes with braces where a single
recipe would suffice. If there's only one action and one set of
conditions, you shouldn't need braces for any of your simple
newbie-level stuff.
:0
* condition
{
:0c
! staff(_at_)example(_dot_)org
}
is just a redundant paraphrase of
:0c
* condition
! staff(_at_)example(_dot_)org
Don't let that c flag confuse you, it won't do anything until all
conditions have been met. (This could perhaps be more explicitly
documented.)
* Elaborate systems where you deliver somewhere else with a :c flag
(perhaps multiple times) and then eventually kill off the message
by delivering it to /dev/null can usually be cleaned up one way or
another.
* A more general phrasing of the previous tip: Make sure you
understand the concept of "deliveredness".
Rants aside, the simple and straightforward way to write that is
:0
* ^Reply-To:(_dot_)*c(_at_)lunar-penguin\(_dot_)com
| formail -i "Sender: cgate(_at_)moongroup(_dot_)com" \
-i "Reply-To: cgate(_at_)moongroup(_dot_)com" \
| $SENDMAIL -oi linuxCprogramming(_at_)listbot(_dot_)com
(skimping on the header rewriting, I just skipped X-Reply-To on the
theory that it won't be seen when it matters, and used Sender in place
of From as per my own suggestion. Are you sure you want to do this for
any Reply-To: where the localpart ends in the letter c?)
:0:
* ^.*
! chuck(_at_)moongroup(_dot_)com
More from the "don't do that" list:
* If you want to do something unconditionally, there's no need to
put in an empty "*" line or a bogus "^TO_.*". Just leave out the
condition line completely.
<...>
* Redundant regular expressions will slow you down.
A trailing .* or (something)? is always completely redundant.
A leading ^.* doesn't serve any useful purpose, either.
and from elsewhere
A typical newbie problem is placing a redundant but harmless lock on a
forwarding recipe. Here's an example:
:0:
* ^TO_johnny(_at_)lunatix\(_dot_)com
! jjasmith(_at_)ppp(_dot_)home(_dot_)in(_dot_)isp(_dot_)net
This will forward to the address jjasmith any mail addressed to
johnny. The trailing colon says to use a lock file, but Procmail can't
figure out what file you want to lock because there is no file
involved anywhere. Indeed, locking doesn't make any sense here, and
you'll get warning messages in the log stating that Procmail "couldn't
determine implicit lockfile." Remove the second colon on the first
line and all will be fine.
Perhaps you want to take a look for yourself; the FAQ is available
from <http://www.iki.fi/era/procmail/mini-faq.html> and, um, I believe
there's a mirror at <http://www.moongroup.com/unix/procmail/>:^)
/* era */
--
Too much to say to fit into this .signature anyway: <http://www.iki.fi/era/>
Fight spam in Europe: <http://www.euro.cauce.org/> * Sign the EU petition