procmail
[Top] [All Lists]

Re: Problem with lists expansion

1997-04-29 09:26:00
"Pascal A. Dupuis" <dupuis(_at_)lei(_dot_)ucl(_dot_)ac(_dot_)be> wrote:
I whish to filter against a list of domains, using files founds on the
www.panix.com WEB server. Things are done this way:

I have an account a panix, and have some familiarity with how they
use these.

CPDOM1=`cat $HOME/filters/cpdomains.1 | tr '\012' '|'`
(That is, the last character is also translated)

Their solution has been to ensure that their is no final new-line
in the files.

This is used within a rule :
:0: cyberpromo
* $^(From|To|Received|Reply-to|X-Sender|Sender):.*(${CPDOM1})
$TRASH

Due to an error, and an /etc/procmailrc that contains "$TRASH=/dev/null"
a whole bunch of people lost all their mail during a four-to-six hour
period. I see this as a further good reason I do not use the shared
filters there.

Doing the substitution, the last condition is empty, wich seems to matches
anything !

Yup. Welcome to regex land. Try this, if you really want to do it:

:0: cyberpromo
* $^(From|To|Received|Reply-to|X-Sender|Sender):.*\<(${CPDOM1}=+(_at_)FAKE@+=)\>
$TRASH

Then you just have to make sure there are no blank lines. The \< and \>
ensure word boundries around the matched domains. Some subscribers to
this list are familiar with my recipes-without-wordboundries-are-rude
rant.

How could I avoid it ( I don't figure how to remove the last char from a
pipe) ? Does more recents version of procmail treat this last | followed
by nothing as something which could be ignored rather than a catchup 
rule ? 

What Panix really wants to know, is why do these fail for files over
about 2000 bytes *even when* LINEBUF=16384 is in the rc file? Currently
they just break the file up into smaller chunks and process each
seperately.

Elijah
------
Please do not CC me when replying to the list.  It is not my responsibility to
prove to you my mail is not spam, if mail to you bounces it will not be resent.

<Prev in Thread] Current Thread [Next in Thread>