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; that would match on your Digex address in a header line that
matched ^TO, or on your other address *anywhere* in the head. That's not
exactly right -- you'd want it to match on your other address only in a
header line that lists recipients -- but in practicality there would almost
never be a difference: when would a piece of email arriving at your Digex
address have your Geocities address in, say, the Subject: or Message-Id: or
From:; not have it in To: or Cc:; match none of your other spam criteria; and
yet contain spam?
So that would probably work as expected, but I think what you really want is
this:
* $ ^TO($MY_ADDRX|pobart(_at_)some\(_dot_)other\(_dot_)domain)
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)
Alternatively, you could include those parentheses in the assignment of
MY_ADDRX:
MY_ADDRX=(pobart@(mail[1-5]?\.)?access[1-5]?\.digex\.net)
| (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.