[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: more concurrencyremote granularity please

To: qmail@xxxxxxxxxxxxx
Subject: Re: more concurrencyremote granularity please
From: David <davidu@xxxxxxxxx>
Date: Wed, 01 Sep 2004 17:37:39 -0700
Delivered-to: de5-qmail@sws5.ornl.gov
Delivered-to: mailing list qmail@list.cr.yp.to
In-reply-to: <1094079409.413653b11b77f@www.gormand.com.au>
Mailing-list: contact qmail-help@list.cr.yp.to; run by ezmlm
References: <20040901215418.GA27990@csi.hu> <1094079409.413653b11b77f@www.gormand.com.au>
Reply-to: David <davidu@xxxxxxxxx>

On Wed,  1 Sep 2004 18:56:49 -0400, Peter Samuel
<peter.samuel@xxxxxxxxxxxxxx> wrote:

> An alternative solution would be to install a second instance of qmail in
> /var/qmail2. Have its smtp daemon listen on port 26. Then in the original qmail
> instance, modify /var/qmail/control/smtproutes and direct the slow domains to

We have used something similar to this as well.  It is very effective.

-davidu

References:
- more concurrencyremote granularity please
  - From: mw-list-qmail
- Re: more concurrencyremote granularity please
  - From: Peter Samuel

Prev by Date: Question/Survey about Serialmail and maildirsmtp...
Next by Date: Developing a granular backup MX application for qmail
Previous by thread: Re: more concurrencyremote granularity please
Next by thread: Re: more concurrencyremote granularity please
Index(es):
- Date
- Thread