Re: [bug-anubis] troubles with 'modify body' (was: add header[] puts headers in body)

[Paolo]

[ splitted follow-up]
On Mon, Sep 13, 2004 at 08:26:31PM +0200, WojciechPolak wrote:
> On Sun, 05 Sep 2004 16:24:45 +0200 Paolo wrote:
> > ---><---
> > 
> > I've stumbled on another couple issues, for 'modify' command:
> > 
> > 1. I'm having troubles to convince 'modify body' work as I understood it.
> 
> The `modify body' modifies message body, not mail header's RHS.
> See 
> [10]http://www.gnu.org/software/anubis/manual/html_node/anubis_40.html#SEC5
> 1

yes, actual example was:

---BEGIN RULE---
if header[X-Domain] "[ ]*mydomain.it"
  modify body :extended [".*X-Cruft:.*"]
fi
---END---

which is meant to remove all body lines with 'X-Cruft:' somewhere, if the
condition on headers is met; this is same as in mentioned manpage (except 
for the :extended, but result is same):

  modify body ["old"]

which doesn't work: anubis -c isues an

  .anubisrc:121: missing replacement value

and rcfile is skipped; it wants '""' after the selecting '[]'.
Perhaps better leave the code as is and correct the manual.

Anyway that's trivial, the real problem comes from apparently correct (to
my understanding) 'modify body' lines:

  modify body :re [".*foo.*"] ""

which doesn't work - worse, breaks things: anubis -c doesn't complain, but
processing stops there with err.9 and this line in tracefile:

  /.anubisrc:121: MODIFY BODY [.*foo.*] [NULL]

[rewriting from my previous posting]
After several tests, seems that there must be an \(\) enclosing _at least_
one re, ie all following seem to work:

  modify body :re [".*foo\(.*\)"] ""
  modify body :re ["\(.*\)foo.*"] ""
  modify body :re ["\(.*\)foo\(.*\)"] ""

I think there's a bug in the [regex] parser, as '.*foo.*' is correct.
      
*But* that doesn't fix completely the problem; it happens that Anubis exits
with an error leaving in tracefile:

  malloc() failed. Cannot allocate enough memory.

what happens is, that in xmalloc() call in

  anubis_regex_replace (...)
    ...
    newstr = xmalloc (newlen);

'newlen' gets a negative value (I've seen -968 in some my case).

Unfortunatly, at present I failed to find the rule for the pattern(s) that
trigger the bug, eg forwarding a msg works, while replying doesn't, and 
conversely on other msg

Anubis was compiled and runs on Debian-Woody, Linux (the kernel) is 2.4.27  

Ideas? is it just me doing things badly wrong? should I switch to pcre
meanwile?

thanks


-- paolo
 
 GPG/PGP id:0x21426690 kfp:EDFB 0103 A8D8 4180 8AB5  D59E 9771 0F28 2142 6690