On Tue, 9 Jun 1998, David W. Tamkin wrote (excerpted for space):
: Paul Bartlett wrote further,
:
: | Would it work in this one recipe to use the following in the conditions?:
: |
: | * $ ^TO($MY_ADDRX)|(pobart(_at_)some\(_dot_)other\(_dot_)domain)
:
: It might; [etc.]
: If the expansion of $MY_ADDRX had been more complex and included top-level
: pipes, I'd recommend this, which wouldn't hurt in any case just in case you
: do put a top-level alternation into $MY_ADDRX some day:
:
: * $ ^TO(($MY_ADDRX)|pobart(_at_)some\(_dot_)other\(_dot_)domain)
:
: [etc.]
This makes sense. I will put it in. Thanks.
: | (BTW, my procmail is still v3.10, which is why I do not use ^TO_.
: | I have no control over that.)
:
: Digex won't let you compile a personal copy of 3.11pre7? Sheesh.
:
The situation concerning invocation of procmail is unclear to me.
When I login to my shell acount, I am on a machine called accessN,
N=1...5. However, incoming mail is handled by pony-N.... procmail is
in /usr/local/bin to me, and a procmail -v shows version 3.10. I sent
a request to the software group asking for an upgrade to v3.11pre7.
The response back was that the mail servers are running v3.11pre7 and
that what is running on the accessN machines is irrelevant.
However, when I accordingly changed my ^TO macros to ^TO_, stuff
went awry. A verbose log revealed that the ^TO macro was what was
being expanded, with the underscore taken as a character to be matched.
That really threw things off. So at this point I don't know whom to
believe or where procmail is running when it processes incoming mail
for me. I could presumably fetch and compile v3.11pre7, but I would
have to store it in my own disk allotment, and if I go over I get
socked with a surcharge, which I don't want. And I don't know whether
it would do any good, anyway.
While I was diddling around with ^TO/^TO_, something really went
haywire big time for several Digex customers, including yours truly, so
that for a time our shells were suspended and we couldn't even login.
(This allegedly was to keep procmail from running at all for us.)
Eventually we were restored on the express provision that we not run
procmail at all! We were told that after a sendmail upgrade (by
Digex), sendmail sessions attributable to our accounts were bringing
the servers to their knees. Seemed a little suspicious to me, but I
really don't have the techie background to know for sure.
Finally I got procmail back but _without_ one of my main anti-spam
recipes (I call it bitbucket.rc). This recipe is INCLUDERC'ed by
numerous spam catchers (after an identifier variable is set), and all
it does is extract information from incoming spams, make a special
one-line log entry for tracking, and deliver the trash to /dev/null.
Now I have to deliver all the garbage to a special folder for manual
deletion. I am going to start pressing them for permission to run
bitbucket.rc soon. I really don't see how this could be effecting
sendmail. bitbucket.rc looks like this:
##################################################
# Normally called in with something like #
# { INCLUDERC=$PMDIR/bitbucket.rc } #
# as the action routine for a recipe. #
# This recipe makes a special one-line #
# entry in the procmail log and then #
# discards the item of mail. #
# $WHICHRC is set in the calling recipe in #
# order to identify that calling recipe. #
##################################################
# Turn on logging so we can record the action
VERBOSE=off
LOGABSTRACT=yes
:0 # When was it mailed?
* ^Date: *\/[^ ].*
{ THEDATE=$MATCH }
:0 # From whom did it come?
* ^From: *\/[^ ].*
{ WHOFROM=$MATCH }
:0 # What is the subject?
* ^Subject: *\/[^ ].*
{ THESUBJ=$MATCH }
# Get message size (recipe from David W. Tamkin)
:0HB # Note trailing period in first condition line
* 1^1 .
* 1^1 ^.*$
* -1^0
{ }
THESIZE = $=
# Log disposition; splitting "" across lines is deliberate
LOG="$WHICHRC - Discarded: $THEDATE $WHOFROM $THESUBJ $THESIZE
"
# Reset logging to what it normally is for our procmail
VERBOSE=$VERBOSITY
LOGABSTRACT=$LOGGING
:0 # Trash this piece
/dev/null
#############################################
If I get bitbucket.rc back, I will more or less be in business,
except that my vacation.rc, which is only invoked when I am out of town
and is just about straight out of the procmail docs, will be hanging
fire, and it _does_ invoke sendmail. (Note that $MY_ADDR and $MY_ADDRX
are different for a reason.)
##################################################
# Change message text as needed (bottom). #
# Normally called in with something like #
# INCLUDERC=$PMDIR/vacation.rc #
# $MY_ADDR is defined earlier in the #
# .procmailrc hierarchy. #
# Normally placed *after* recipes doing #
# special filtering and just before all #
# non-filtered mail drops into default #
# mailbox. #
##################################################
:0 # When was it mailed?
* ^Date: *\/[^ ].*
{ INDATE=$MATCH }
:0 # What is the subject?
* ^Subject: *\/[^ ].*
{ SUBJECT=$MATCH }
# Weed out special cases which should *not* receive notice.
# Have formail check to see if this sender has already received notice.
:0 Whc: vacation.lock
* !^FROM_DAEMON
* $ !^X-Loop: $\MY_ADDR
* !^Precedence.*junk
* !^Precedence.*bulk
* !^Precedence.*list
| formail -rD 8192 $PMDIR/vacation.cache
:0 ehc # If the name was not in the cache, send a notice.
| (formail -rA"Precedence: junk" \
-A"X-Loop: $MY_ADDR"; \
echo "Your mail arrived dated: $INDATE"; \
echo "and concerning Subject: $SUBJECT"; \
echo "but I am away until approximately 1998.05.31."; \
echo "I will attend to it upon my return. -- Paul Bartlett <$MY_ADDR>" \
) | $SENDMAIL -oi -t
--
Paul <pobart(_at_)access(_dot_)digex(_dot_)net>
..........................................................
Paul O. Bartlett, P.O. Box 857, Vienna, VA 22183-0857, USA
Finger, keyserver, or WWW for PGP public key
Home Page: http://www.access.digex.net/~pobart