Re: [bug-anubis] GNU Anubis 4.0 released.

[Paolo]

On Sat, Jan 01, 2005 at 01:17:34AM +0100, Paolo wrote:
> On Fri, Dec 31, 2004 at 08:22:19PM +0100, Paolo wrote:
> > On Sat, Dec 18, 2004 at 02:47:28PM +0100, Wojciech Polak wrote:
> > > Hello,
> > > 
> > > The Anubis Team is pleased to announce the release of GNU Anubis 4.0.
> > > The release is available by anonymous FTP from:
> > > 
> > >     ftp://ftp.gnu.org/gnu/anubis/anubis-4.0.tar.gz
> > 
> > sorry to bring bad news - it still crashes in my setup, like 3.9.9x used
> > so far, all being equal to previous reports:
> > 
> ...
> > Time to look at pcre, hoping this bug is confined to regex (glue)code, till
> > someone manage to smash it.
> 
> [following-up myself, while last dusts of 2004 settle..]
> 
> actually, I realized that :re, :extended, :perl seem to work nomore in
> 4.0; I tried a single 'modify body' line:
> 
>  modify body :perl ["[[:blank:]]*X-Anomy.*"] ""
> 
> but anubis crashes on it - I get
> 
>  > [11139] Reading user configuration file /home/prel/.anubisrc...
>  [11139] pcre_compile() failed at offset 4: unknown POSIX class name.
>  > [10975] Child [11139] finished. Terminated on signal 11. 0 clients left.
> 
> yet the pcre sounds correct - at least:
> 
>  perl -p -e 's/[[:blank:]]*X-Anomy.*//'
> 
> does what's expected. I tried '["\s*X-Anomy.*"]' as well, this time anubis 
> doesn't crash, but does nothing - ie doesn't mangle lines like above perl
> in-line.
> 
> Also, now both
> 
>   modify body :extended ["[[:blank:]]*X-Anomy.*"] ""
>   modify body :basic ["[[:blank:]]*X-Anomy.*"] ""
> 
> do nothing, lines that should be removed are left untouched. Yet, again, 
> sed(1) works as due with such re.
> 
> Here's the relevant trace:
> 
>  ... .anubisrc:68: Section RULE
>  ... .anubisrc:122: MODIFY BODY [[[:blank:]]*X-Anomy.*] [NULL]
> 
> What am I missing?
> 
> anubis --show-config-options
> REGEX
> PCRE
> OPENSSL
> LIBWRAP
> NLS

[2004 dusts settled - following-up myself again]
 
ok, found the problem, 'modify body' doesn't act 'cause it doesn't see the
body: it happened on that particular msg, also with external bodyproessor, 
there seems to be a glitch in header-body recognition; here's the relevant 
excerpt in original msg (last header lines, first body lines, cut to 
70chars for clarity):

-*-*-
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=3036.01_1_539244940_1658


address@hidden
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

.

address@hidden
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


   [bottiglia.jpg]  [1]HOME=20
   [2]NOVITA'       [3]VIBROMASSAGGIATORE=20
-*-*-

bouncing this msg from mutt (I'm using my modified msg2smtp.pl), anubis'
trace shows:

-*-*-
CLIENT >>> MIME-Version: 1.0(19)
CLIENT >>> Content-Type: multipart/alternative; boundary="3036.01_1_53
CLIENT >>> Resent-From: address@hidden(43)
CLIENT >>> Resent-Date: Sat, 1 Jan 2005 10:51:21 +0100(45)
CLIENT >>> (2)
CLIENT >>> (2)
CLIENT >>> address@hidden
CLIENT >>> Content-Type: text/plain(26)
CLIENT >>> Content-Transfer-Encoding: 8bit(33)
CLIENT >>> (2)
CLIENT >>> .. (5)
CLIENT >>> (2)
CLIENT >>> address@hidden
> [29844] Executing /usr/local/bin/sedbbox.sh norm ...
SERVER <<< Envelope-to: <address@hidden>(33)
SERVER <<< Return-path: <address@hidden>(40)
-*-*-

putting a '|tee .anubislog.log' in /usr/local/bin/sedbbox.sh I got just
'..' in that log, which is the single '.' in original msg, doubled to 
prevent signaling EOF to MTA.
So anubis assignis just those '..' to body, and feed it to body processor 
(internal/external), while the rest of msg is passed on unaltered - perhaps
as if it was headers (after body?).

-- 
 paolo
 
 GPG/PGP id:0x21426690 kfp:EDFB 0103 A8D8 4180 8AB5  D59E 9771 0F28 2142 6690
 "Indeed, it does come with warranty: it *will* fail, sometimes, somehow..."
                                                           - software vendor