Mailing List Archive

Replacement mbox.c (using ripmime)
nice to see this mailinglist livening up a bit.

> That far I don't go; if a simple networking parent can't remain
> stable and alive, I'll hunt it down and fix it. Or delete it.

Obviously.

However, we have a reasonable number of systems out there at client's
sites (we install Linux into small businesses who can't afford NT) and
they don't half scream when their e-mail goes down. So any tool that
keeps it up is worth it in my book.

Having an init to run an init seems a bit OTT, but running the master
through inittab is well worth it. It really bugs me when daemon's don't
have a "-f" option, cos it means I can't run them through inittab.

> and each child rolled a random number uniformly between those two

Good point.

> On sick, sick platforms this produces errors,

I've never heard that before. Useful knowledge. I assumed all platforms
could run multiple child accepts.

> written in perl, it probably isn't directly useful

Too true. My project No.2 is to re-write SpamAssassin in "C", unless
anyone knows a version ? Anyone know if libpcre is any good ?

> {Apache} Indeed, but it's solving a harder problem

Yes, and no ... desktop users don't like having to wait to send their
mail... if there aren't enough scanner processes available, then the
user will be told "Try again later". They don't like that !


James
Re: Replacement mbox.c (using ripmime) [ In reply to ]
2003-09-05T11:13:01 James Stevens:
> > On sick, sick platforms this produces errors,
>
> I've never heard that before. Useful knowledge. I assumed all platforms
> could run multiple child accepts.

The one I know about is Solaris 2.5.1 (fixed in 2.6, I
believe). Sick minds come in clutches, though, so even if there's
no Solaris 2.5.1 in your future, it's worth keeping the obscure
possibility in mind.

> > {Apache} Indeed, but it's solving a harder problem
>
> Yes, and no ... desktop users don't like having to wait to send their
> mail... if there aren't enough scanner processes available, then the
> user will be told "Try again later". They don't like that !

Ahh, this is a different deployment model.

I wouldn't dream of deploying something that's attempting a
near-impossible job, like MIME scanning, directly where clients can
hammer it.

Clients would submit to an MTA (I favour Postfix) which would
do whatever fast (constant-time!) front-end checks (anti-relay
at a minimum) they must and then enqueue the message and accept
committment for it. The client can go away. That front-end queue
drains through the hideous chain of disgusting hacks that try (and
sometimes succeed) to undo all the damage that Microsoft has done
to the world. Users wouldn't see their pacing, and the queue-drain
would manage the maximum concurrency that the mime hackers attempt
to run with.

-Bennett
Re: Replacement mbox.c (using ripmime) [ In reply to ]
> Having an init to run an init seems a bit OTT, but running the master
> through inittab is well worth it. It really bugs me when daemon's don't
> have a "-f" option, cos it means I can't run them through inittab.

You don't need "-f" in clamd, just uncomment the "Foreground" option in
clamd and strt it with "clamd --config-file=/your/config/file".

> Too true. My project No.2 is to re-write SpamAssassin in "C", unless
> anyone knows a version ? Anyone know if libpcre is any good ?

Oh, that's a good question. Is the libpcre library stable ? I'm going
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