[Fwd: Re: production mail server in Perl, was Re: asynchronous execution]

--=-2T8mvgnRKsXiLdtN2Q+h
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

- forgot to include the list in the original message

--=-2T8mvgnRKsXiLdtN2Q+h
Content-Disposition: inline
Content-Description: Forwarded message - Re: production mail server in
	Perl, was Re: asynchronous execution
Content-Type: message/rfc822

Subject: Re: production mail server in Perl, was Re: asynchronous execution
From: Aaron Johnson <[email protected]>
To: Dave Rolsky <[email protected]>
In-Reply-To: <[email protected]>
References: <[email protected]>
	 <[email protected]>
	 <[email protected]>
Content-Type: text/plain
Organization: 
Message-Id: <[email protected]>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.2.0 
Date: 26 Nov 2002 19:34:59 -0500
Content-Transfer-Encoding: 7bit

On Tue, 2002-11-26 at 17:50, Dave Rolsky wrote:
> On Tue, 26 Nov 2002, Stephen Adkins wrote:
> 
> > Similar to my question earlier about an all-Perl HTTP server,
> > I have asked myself whether there is a production-quality all-Perl
> > mail server.  This would allow you to write code in Perl to
> > process mail messages without forking a Perl interpreter per
> > message.
> 
> Exim 4 embeds a Perl interpreter in the daemon.
> 
> 
There is a project, designed for use with XMail
(http://www.xmailserver.com), that provides a Perl daemon to process
messages.  It can work local or remote via samba or NFS shares.  It
isn't a standalone mail server, but provides message filters for
incoming messages (outgoing will be supported in later releases of
XMail).  It comes with a SpamAssassin (http://www.spamassassin.org) and
virus procedure (filter).

I am still testing it, but it works good so far.  I am using it for
SpamAssassin and Mhonarc (http://www.mhonarc.org).  It also has a nice
"procedure" system that allows for plugins.
Its flying under the name 'Scope' right now.
http://www.saltstorm.net/depo/scope/

It is Linux and Windows compatible (most likely any UNIX though) and
uses a small C++ binary to avoid the overhead of a invoking the Perl
interpreter to hand the information to the Perl daemon.

I find that is the best of both worlds.  The developer of the email
server isn't worried about my needs for parsing/processing each message
and all I need to know is where to add the line that passes the info the
Perl daemon.  We can each focus on our domain.

I don't want everything to be in Perl because somethings are better
managed or gain performance based in other languages.  When I can use
Perl to fill in the gaps and not have to know the internals of the other
server, then I feel it is a big win for everyone.

The Scope project to me represents a SOAP/RPC structure.  This same base
could be modified to be the base of a Perl Application server possibly.

It might be similar in some respects to PureMessage from ActiveState,
but I haven't worked with PureMessage so I can't be sure.

Aaron

> -dave
> 
> /*==================
> www.urth.org
> we await the New Sun
> ==================*/
> 
> 

--=-2T8mvgnRKsXiLdtN2Q+h--