** This message is being resubmitted from the modperl discussion ** mailing list. Someone suggested that we should write an article ** about using Apache as a mail proxy -- anyone know how we can get ** that done?
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/~mock/Apache-SMTP-0.01/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! TTUL Ken Frank Wiles [30/11/04 13:30 -0600]: > On Tue, 30 Nov 2004 19:23:38 +0000 > [EMAIL PROTECTED] wrote: > > > Please let me raise a question. > > > > In practice, people who can program in other phases usually can > > 1) program directly in C module; and 2) find that C provides > > much better a solution. > > > > For example, the authz phase in the dual-Apache setup. > > Here the static files are served by the light Apache. A C > > autenz handler is usually more efficient and may be a must. > > > > The same is true for the URL re-writing phase. Most likely we > > need the URL to be re-written for both dynamic contents and > > static files. > > > > So, while mod_perl is able to handle other phases, in practice, > > one may still need to go back to the C API for the best results. > > > > In the content phase, I think the OO programming, and so > > the MVC (Model-View-Control) concept, makes mod_perl > > much better a choice than PHP for large projects. > > I think you will find that mod_perl code is roughly the same > speed as a comporable C Apache module. Since mod_perl holds all of > the code in memory we don't have a fork/compile/excute problem which > is why most people think C is way faster than Perl. > > I've seen non response phase handlers, written in mod_perl, handle > better than commercial C modules. I'm curious why you think a C > module would be a better solution? > > --------------------------------- > Frank Wiles <[EMAIL PROTECTED]> > http://www.wiles.org > --------------------------------- > > > -- > Report problems: http://perl.apache.org/bugs/ > Mail list info: http://perl.apache.org/maillist/modperl.html > List etiquette: http://perl.apache.org/maillist/email-etiquette.html > > > Sent by MailChannels: http://www.mailchannels.com -- MailChannels: Assured Messaging -- Eliminate Critical False Positives http://www.mailchannels.com MailChannels Corporation Suite 1600, 1188 West Georgia St. Vancouver, BC, Canada Ken Simpson, CEO +1-604-729-1741 Sent by MailChannels: http://www.mailchannels.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html Sent by MailChannels: http://www.mailchannels.com Sent by MailChannels: http://www.mailchannels.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
