On Mon, Oct 23, 2000 at 12:19:57PM -0500, guenther+procmail(_at_)gac(_dot_)edu
wrote:
Jeff Howie <Jeff(_dot_)Howie(_at_)federated(_dot_)ca> writes:
On Fri, Oct 20, 2000 at 11:21:32PM -0400, Stan Ryckman wrote:
[snip]
The blank line after "Lines: 85" ends the header; the rest, which
look like former header lines, are now in the body (as far as mbox
format is concerned).
...
I don't know how it might have got messed up; however, I speculate
that it may be related to that long Path: header present in the
"BAD" message. (I'm suspicious because it appears to have been
truncated -- note that it ends with a "!" -- , and the amount that
came through is just under 256 characters.)
Also note that the first line of the 'body' was the final component of
the broken path. There's some command in the chain before procmail
which can't handle very long header fields.
Hmmmm, I wonder, would $LINEBUF matter here? I don't think it
should, but you might try something like
That doesn't matter. Procmail doesn't care how long the lines in the
message are. The message could have *no* newlines and include NULs for
all procmail cares. LINEBUF is the limit on rcfile line length before
and after variable and command expansions.
I thought the blank lines looked suspicious too, but again not knowing
very much about this, I wasn't sure.
You should track down where very long headers are broken in the steps
getting to your mailbox and get the broken program fixed.
How can I get procmail to search the _entire_ message (body) for the
string:
'To: comp.os.linux'
for example, instead of just the header? It doesn't seem like:
:0:
* To:.*comp.os.linux
comp.os.linux
To quote the procmailrc(5) manpage:
A line starting with ':' marks the beginning of a recipe.
It has the following format:
:0 [flags] [ : [locallockfile] ]
<zero or more conditions (one per line)>
<exactly one action line>
...
Flags can be any of the following:
H Egrep the header (default).
B Egrep the body.
So, you want both the 'H' and 'B' flags on the recipe. Also, don't you
want to anchor the match against the start of the line? As it was, your
regexp would match other headers fields like
Reply-To: Philip Guenther
<guenther+comp(_dot_)os(_dot_)linux(_at_)gac(_dot_)edu>
Assuming you don't want that, I've added a '^' to the regexp.
:0 HB:
* ^To:.*comp\.os\.linux
comp.os.linux
Does that make sense?
Yes, that does make sense. I was actually working in that direction
myself, both with the start of the line anchor & the tags. The rule I
came up with was almost the same:
:0HB:
* ^To:.*comp.os.linux
comp.os.linux
Note the lack of the space in the tags, and the lack of escaping the
'.'. The space doesn't seem to make a difference, but the backslashes
crippled the rule (works fine without them). Does a regexp have to be
quoted if there's backslashes (I think in (GNU)grep it does)? I'll try
this out, as I'd like to get the rule as discriminating as possible.
thks.jeff
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail