** 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
> modperl@att.net 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 <frank@wiles.org>
> 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: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org
** 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
> modperl@att.net 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 <frank@wiles.org>
> 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: advocacy-unsubscribe@perl.apache.org
For additional commands, e-mail: advocacy-help@perl.apache.org