Out of curiosity, I moved all those domains back to my morercpthosts,
rehashed it (qmail-newmrh) and tried sending mail to the domains that
weren't working before. Everything looked fine. I'm totally confused now.
As I have no locals entries outside of default, and absolutely no
virtuals, I don't see how any of that could have had any effect.
Here is output from my qmail-showctrl (minus the 6800+ entries)
badmailfrom: (Default.) Any MAIL FROM is allowed.
bouncefrom: (Default.) Bounce user name is MAILER-DAEMON.
bouncehost: (Default.) Bounce host name is imlspool001.datareturn.com.
concurrencylocal: Local concurrency is 50.
concurrencyremote: Remote concurrency is 509.
databytes: (Default.) SMTP DATA limit is 0 bytes.
defaultdomain: Default domain name is datareturn.com.
defaulthost: (Default.) Default host name is imlspool001.datareturn.com.
doublebouncehost: (Default.) 2B recipient host: imlspool001.datareturn.com.
doublebounceto: (Default.) 2B recipient user: postmaster.
envnoathost: (Default.) Presumed domain name is imlspool001.datareturn.com.
helohost: (Default.) SMTP client HELO host name is
imlspool001.datareturn.com.
idhost: (Default.) Message-ID host name is imlspool001.datareturn.com.
localiphost: (Default.) Local IP address becomes
imlspool001.datareturn.com.
locals:
Messages for localhost are delivered locally.
Messages for imlspool001.datareturn.com are delivered locally.
me: My name is imlspool001.datareturn.com.
percenthack: (Default.) The percent hack is not allowed.
plusdomain: Plus domain name is datareturn.com.
qmqpservers: (Default.) No QMQP servers.
queuelifetime: (Default.) Message lifetime in the queue is 604800 seconds.
rcpthosts:
SMTP clients may send messages to recipients at localhost.
SMTP clients may send messages to recipients at imlspool001.datareturn.com.
morercpthosts:
(6800+ entries omitted)
morercpthosts.cdb: Modified recently enough; hopefully up to date.
smtpgreeting: (Default.) SMTP greeting: 220 imlspool001.datareturn.com.
smtproutes: (Default.) No artificial SMTP routes.
timeoutconnect: (Default.) SMTP client connection timeout is 60 seconds.
timeoutremote: (Default.) SMTP client data timeout is 1200 seconds.
timeoutsmtpd: (Default.) SMTP server data timeout is 1200 seconds.
virtualdomains: (Default.) No virtual domains.
Here is my /etc/qmail/control directory. As you can see, the modified time
on my locals file is back in Nov of 2000.
-rw-r--r-- 1 alias nofiles 3 Apr 6 2000 concurrencylocal
-rw-r--r-- 1 alias nofiles 4 Jul 14 2000 concurrencyremote
-rw-r--r-- 1 alias nofiles 15 Nov 6 2000 defaultdomain
-rw-r--r-- 1 alias nofiles 37 Nov 6 2000 locals
-rw-r--r-- 1 alias nofiles 27 Nov 6 2000 me
-rw-r--r-- 1 alias nofiles 115504 May 16 23:40 morercpthosts
-rw-r--r-- 1 alias nofiles 275516 May 16 23:40 morercpthosts.cdb
-rw-r--r-- 1 alias nofiles 15 Nov 6 2000 plusdomain
-rw-r--r-- 1 alias nofiles 37 May 16 23:34 rcpthosts
Christopher Tolley writes:
>
> This server has NO virutal entries at all. There isn't even an
> /etc/qmail/control/virtualhosts file. It's sole purpose is to act as a
> backup mail server when the primary MX's for any of the 6800+ domains
> aren't working.
>
> Outside of the server's own hostname and localhost, there are no other
> entries in the /etc/qmail/control/local entries at all.
>
> The only qmail files that were ever modified on a regular basis before this
> problem were morercpthosts and morercpthosts.cdb.
>
> In my original email, I mentioned that I had restarted qmail (qmail-send)
> with no effect. The errors only stopped once I had migrated all the
> domains from morercpthosts/morercpthosts.cdb to rcpthosts (which took
> effect immediately with no need for restart).
>
> Even on the servers I maintain that DO have virtualhost entries, I've never
> had to HUP qmail-send to have the changes take effect unless vadddomain of
> vpopmail automatically sends a HUP.
>
> My original questions stand: Are there limits to the number of entries in
> morercpthosts/morercpthosts.cdb? I really don't have a problem with
> maintaining a completely flat-text rcpthosts, but a binary morercpthosts
> would be more efficient.
>
> According to the doco's I've read about rcpthosts and morercpthosts.cdb,
> morercpthosts.cdb is effectively appended to rcpthosts, but is read faster
> due to the hashing. In the case of my 6800+ domains, I would like to stick
> to the most efficient method, as this list is only getting bigger by the
> day.
>
> Do I need to HUP something after making changes to morercpthosts.cdb? I've
> never had to do that before. Changes always seemed to be immediate in the
> past.
>
> Any other insight would be greatly appreciated.
>
> -CT
>
>
> Chris Johnson writes:
>
> > On Wed, May 16, 2001 at 11:24:44PM +0000, Christopher Tolley wrote:
> > >
> > > I wish it were that simple. Here is the log entry with error:
> > >
> > > May 16 13:18:10 spoolserver qmail: 990037090.207318 delivery 2882: failure:
> > > Sorry._Although_I'm_listed_as_a_best-pref
> > >
>erence_MX_or_A_for_that_host,/it_isn't_in_my_control/locals_file,_so_I_don't_treat_it_as_local._(#5.4.6)/
> > >
> > > As this error was occuring (multiple times) I checked the morercpthosts.cdb
> > > and morercpthosts files. Both files contained the entry for the domain in
> > > question. Once I copied all the entries from morercpthosts to rcpthosts,
> > > the errors stopped and mail was spooled properly.
> >
> > This was a coincidence. rcpthosts and morercpthosts have nothing to do with
> > this error. Those files are consulted *only* by qmail-smtpd, and only when it's
> > deciding to accept or reject a RCPT TO address during the SMTP conversation.
> > The above error message is generated by qmail-send, after qmail-smtpd has
> > already queued the message and died.
> >
> > My guess is that you added an entry to locals or virtualdomains and didn't HUP
> > or restart qmail-send. At some time in the course of screwing with your
> > rcpthosts files you restarted qmail, so that your locals/virtualdomains changes
> > took effect and things started working again.
> >
> > Chris
>
-CT
