|There's more than one way to do things|
Mail::Audit as demon?by swiftone (Curate)
|on Sep 20, 2002 at 14:14 UTC||Need Help??|
swiftone has asked for the
wisdom of the Perl Monks concerning the following question:
Some time ago I got my DSL setup, and finally had a perm. IP and a pretty stable connection, so I setup my box (Debian Linux) to act as my mailserver and had all my accounts forward to there.
Then my DSL borked. There was gnashing of teeth and fuming and saying of unkind words. Resetting the DSL restored my connection, and mail did pour forth from the ether(net) into my box.
Which slowed to a crawl. A slow crawl.
Granted, that only lasted about 5-10 seconds, and it filtered several hundred messages in addition to everything else my (none too powerful) box was waiting for a connection to do, but it was an annoyance and a surprise. I could live quite happily without ever changing anything, but I can't leave well enough alone.
My understanding of the issue is that each message launches a perl script, and thus the perl interpreter. In essence, the Apache Perl CGI problem. So I started thinking about fixing it in a similar vein to mod_perl. Comments? I know other solutions exist that involve playing with the mailserver, but I like the general elegance and flexibility of a script called from a .forward file.
So: Is it possible to have my filter running as a demon, and have something small and quick, say, a simple C program, hand off the mail to the demon for filtering? Well, I know it is possible, so would this have any impact on the efficiency of the filtering? I don't really have a need for it, but would something like this make Mail::Audit a more friendly solution for ISPs and the like? I'm sure this could be set up as a mod_perl solution and have everything filter through that, but I don't want to subscribe to the "everything in HTTP" crowd, and my idea is to make the prequisites easy, not forcing someone to run mod_perl if they don't want to.