Mailing List Archive

Replacement mbox.c (using ripmime)
> Ok, so I decided to give this a try just to see if it made a
> difference to the clamd crashes I'm seeing. No crashes, but I
> don't think it's catching any viri either. Without the '--mailbox'
> argument to ripmime, all I get is one large text file, it doesn't
> actually pull apart the mail message. You can't add the --mailbox
> because that requires a file argument, not STDIN.
>
> Are you sure this is really doing what you think it's doing?

You are right, in fact I added the "--mailbox" option shortly after
posting the messages.

Without the --mailbox option ripmime will only do one message, but as I
am only using "clamd" to scan incomming e-mail, using the clamav-milter,
missing the "--mailbox" option worked fine for me.

However, as you said, "ripmime" in "--mailbox" mode doesn't support
STDIN, but that is dead easy to fix. I have ripmime v1.3.0.4, in the
file "mime.c", find line 2097 would read :-

fi = fopen(mpname,"r");

Change it to read :-

if (strcmp(mpname,"-")==0) fi = stdin; else fi = fopen(mpname,"r");

then re-compile and re-install ripmime. I have posted this to Paul (who
owns ripmime) and he has included it in the next release.


My next project, is to add "libripmime" into "libclam", so that the
ripmime code can be called directly by "libclam", thus avoiding the
"fork()" and "exec()", both of which are relatively expensive system
calls - although even this is still faster than using the original "mbox.c".

However, this requires that the "MIME_unpack_mailbox" and "MIME_unpack"
calls can accept a file descriptor, or file pointer, as well as, or
instead of, the filename. Again, this is a trivial change, which Paul
has also agreed to include in a future release of ripmime.


I stopped bothering to post to the clam-devel mailing list, because
nobody seemed interested in what I was doing. What's more the latest
August snapshot still leaks like hell (mostly in the mbox.c code) and
crashes (SEGV) even though I have specifically provided Nigel with two
e-mails that demonstrate the SEGV problem.

Usign ripmime, with the addition of the "--mailbox" flag, I have had
"clamd" running fine for a while now and it leaks a lot less then the
original code. On my 375 test e-mails, all releases and snapshots of
"clamd" crash before completing the test and generally leak about 12Mb.
Ripmime+clamav only leaks about 200Kb, and was 12 seconds (out of 89
seconds) faster.

What I also want to try next is the 20030829 snapshot of clamav, but
with ripmime, and then with libripmime! Nigel says he has cured a number
of leaks, so that may reduce the 200Kb leak further.

<RANT>I'm not sure I really understand why Tomasz / Nigel seem so
reluctant to use ripmime / libripmime, when it seem to be to be a better
solution, and will soon have OLE unpacking support</RANT>

BTW: My clamav experience is that 20030720 is the best release to work
with, but I haven't looked into 20030829 in detail, yet, as getting the
system stable is my highest priority - I can't be without my e-mail!



James
Re: Replacement mbox.c (using ripmime) [ In reply to ]
> <RANT>I'm not sure I really understand why Tomasz / Nigel seem so
> reluctant to use ripmime / libripmime, when it seem to be to be a better
> solution, and will soon have OLE unpacking support</RANT>

If I remember correctly, the license of libripmime doesn't allow us to use it
in libclamav.

Best regards,
Tomasz Kojm
--
oo ..... zolw@konarski.edu.pl
(\/)\......... http://www.konarski.edu.pl/~zolw
\..........._ I nie zapomnij kliknac w brzuszek...
//\ /\\ <- C. Amboinensis www.pajacyk.pl
Re: Replacement mbox.c (using ripmime) [ In reply to ]
I'm sure pcre is stable enough for libclamav. ;-)

On Monday, 2003-09-08 at 05:11:32 AM, Tomasz Kojm scribbled:
*snip*

>
> Oh, that's a good question. Is the libpcre library stable ? I'm going
> to use it in libclamav.

--
Benjamin Lee
Melbourne, Australia "Always real." http://www.realthought.net/

__________________________________________________________________________
Every nonzero finite dimensional inner product space has an orthonormal basis.

It makes sense, when you don't think about it.