################################################### # WARNING: Do not edit this file! # If you do the changes will be lost! # Instead edit the corresponding .txt file and run make.pl # # Don't forget to commit the changes to both .txt and the generated # .pod to svn, since others won't run the local make.pl #################################################### =head1 NAME Running email through mod_perl 2.0 =head1 Ken Simpson Eksimpson (at) ghpbjymdczr.mailchannels.comE exclaimed: =over =item * Date: Mon, 6 Dec 2004 14:15:25 -0800 =item * Traffic: Low (in development) =item * URL: http://www.mailchannels.com/opensource/ =back We have been using mod_perl successfully for several months now as a flexible email proxy -- we just wrapped Net::Server::Mail and with a few additional hacks and it worked. Matt Sergeant did the same thing with qpsmtpd and I have heard that the performance results were initially very promising (http://msgs.securepoint.com/cgi-bin/get/qmail0411/120/1/1/1.html). More details of our hack (patches etc.) are at http://www.mailchannels.com/opensource and http://search.cpan.org/dist/Apache-SMTP/lib/Apache/SMTP.pm. IMHO, using mod_perl as a general application server is a great idea. For us there really was no other viable alternative. We looked at POE, Sendmail's milter API, Net::Server and of course qpsmtpd but the reliability, portability, and scalability of Apache was what caused us to go through the effort of making our bits work on mod_perl. To configure a mail server, it's just a matter of adding a VirtualHost section to the Apache configuration et voila. And as packages such as mod_throttle move over to Apache 2, we will gain the wonderment of a solid resource management tool for mail traffic. Joy! Regards, Ken =cut