On Thu 1999-02-18 (08:10), [EMAIL PROTECTED] wrote:
> On Thu, 18 Feb 1999, Peter van Dijk wrote:
> 
> > On Wed, Feb 17, 1999 at 12:33:04PM -0500, [EMAIL PROTECTED] wrote:
> > > On Wed, 17 Feb 1999, Chris Naden wrote:
> > > 
> > >   for qmail-send: for its description of locals to explicitly say that
> > >   virtual domains should *not* be placed in locals?
> > > 
> > >   for qmail-smtpd: for its description of rcpthosts to say that it
> > >   should contain all the hosts in locals and virtualdomains plus
> > >   those hosts you act as MX for.
> > > 
> > > Actually, in stead of the latter suggestion, I'd prefer that there be
> > > another control file: mxhosts, and drop rcpthosts, which is just
> > > confusing everyone.  Then we have simple explanations for what goes where.
> 
> > You're not saying that qmail-smtpd should just read in locals and
> > virtualdomains and accept mail for all domains in there, right?
> 
> No.  I was suggesting replacing rcpthosts with mxhosts and having
> smail-smtpd read virtualdomains, locals and mxhosts.  Having looked at
> "man qmail-control" I've decided that the reason Dan did things this way
> is that qmail-smtpd only has to read/check one file (rcpthosts), rather
> than three (virtualdomains, locals and mxhosts).  It's a typical tradeoff:
> simpler program vs requiring people to read the documentation and put the
> right things in rcpthosts.

I quite like the way Dan has made rcpthosts work. It allows you to easily 
specify who you'll receive mail for in one place. The only thing that I'd
like is for the behaviour when rcpthosts doesn't exist to change. Since the
"normal" thing is for rcpthosts to be locals + virtualdomains I think that
this should be the default if rcpthosts doesn't exist.

  - Keith
-- 
Keith Burdis - MSc (Com Sci) - Rhodes University, South Africa  
Email   : [EMAIL PROTECTED]
WWW     : http://www.rucus.ru.ac.za/~keith/
IRC     : Panthras                                          JAPH

"Any technology sufficiently advanced is indistinguishable from a perl script"

Standard disclaimer.
---

Reply via email to