From: Jason Ashbaugh <jason@...111.com>
Date: 2002-12-23T13:29:49+09:00
Subject: Re: smtp server (OT)

On the issue of integration:

Qmail's greatest success nowadays seems to lie in acting as a 
gateway/relay for inbound or outgoing email. In effect as a 
virus/spam/rbl warden in either direction. It doesn't integrate that 
well with commercial packages simply because it is designed to deliver 
mail to a Unix system (maildir or mbox) or forward the messages to the 
server designated to deal with the domain. I use it as an inbound 
guardian since I can run every inbound email first through ORBS, then 
through both McAfee and F-Prot virus scanners, then finally through 
spamassasin to give it a spamrating for users who want to filter that 
way. It currently forwards to an exchange server (ick) but I hope to 
switch over to communigatepro this summer (which does have good hooks 
for running external filters... might be a good place to throw some ruby).

OT, and promising not to conitnue unless asked,
Jason

Ben Schumacher wrote:

>Jason Ashbaugh said:
>  (...snip...)
>  
>
>>My recommendation would be to always if possible use Qmail (I know it's
>>apain to configure at first, but it is bulletproof in security) for smtp
>> functions wherever possible. A good project might be to write a
>>configuration utility in ruby that handles wmail underneath....
>>
>>Just the thoughts of a security admin.
>>    
>>
>
>I would be forced to agree with Jason on this one. qmail does have a solid
>security model, and is an excellent SMTP server. It is, also, extremely
>flexible, and I would wager than anything you're trying to do you could do
>with a stock (read: no patches) qmail installation. If, for some reason,
>you need control of the queue interaction (some sort of message
>filtering), then check out the qmail-queue patch. This should give you
>what you need, and its easy to write a Ruby program to interface with
>qmail at this level. (I've done it a couple times.)
>
>If it is an issue of integration (you have a project that needs SMTP-like
>abilities), then I would still try to use qmail where possible. The only
>problem with this solution in that case is the fact that it can't be
>packaged with a commercial product, however, it is great for internal
>uses.
>
>Cheers,
>
>bs.
>
>
>
>
>  
>