I have an interesting issue that I have not been able to fix in the
past couple weeks.
I'm setting up a new mail system (8.3.15) in parallel to our older
system (8.12.xx). And am running into the following.

The system is fairly simple
Main system is a masquerading smart host for outgoing mail, and the
final destination for incoming and local mail.

Hub sendmail.mc
--------------------------
MASQUERADE_AS (`mailhost.wanted.domain.name')
FEATURE(`allmasquerade')
FEATURE(`masquerade_entire_domain')
FEATURE(`masquerade_envelope')
FEATURE(`always_add_domain')
MASQUERADE_DOMAIN(`wanted.domain.name')
EXPOSED_USER(root)

MAILER(`local')dnl
MAILER(`smtp')dnl
MAILER(`procmail')dnl

All the clients are nullclients adding the fully qualified domain

client submit.mc
-----------------------
FEATURE(`msp', `[127.0.0.1]')dnl

client sendmail.mc
----------------------------
FEATURE(`no_default_msa')dnl # Turn off the listener (port 25)
DAEMON_OPTIONS(`NAME=NoMTA4, Family=inet, addr=127.0.0.1')dnl
DAEMON_OPTIONS(`NAME=MSA4, Family=inet, addr=127.0.0.1, Port=587.
M=E')dnl
FEATURE(`always_add_domain')dnl
FEATURE(`nullclient',`mailhost.wanted.domain.name' )dnl


Here's the issue, sending mail from client causes the mail daemon on
mailhost to pause for 10 minutes with a 5.3.5 error:

Sep 18 13:02:47mailhost MTA[29875]: [ID 801593 mail.info]
k8IJ2lfC029875: --- 554 5.0.0 MX list for client.wanted.domain.name.
points back to mailhost.wanted.domain.name (hold)

Sep 18 13:02:47 mailhost MTA[29875]: [ID 801593 mail.info]
k8IJ2lfC029875: --- 554 5.3.5 Local configuration error (hold)


I put an MX record for the client machine alone into DNS, so the 1st
message is OK (I think).

10 minutes later, the message is submitted to the mail queue with
sender and recipient OK and a delay of 10:00:00, xdelay=0:00:0,
ntries=1
The message then sits in the queue for another 10 minutes and is
successfully delivered w/ the same delay and ntries values.

I've searched this list, sendmail, both Bat books, google, and cannot
find anything like this.
I've also tried various settings in local-hostnames, mailertable, etc.
and other than I've managed to break my masquerading that was working
previously, the same result is consistant.

send the mail, connection lasts for 10 minutes till the mail is
delivered to the mail queue, where it sits for another 10 minutes till
it is successfully delivered.

I'm out of ideas!!
Any suggestions on things to try/look at would be greatly appreciated.
I need to get this functional so I can move toward full site testing of
this system.

Thanx
Bruce Lundberg

> I'm out of ideas!!
> Any suggestions on things to try/look at would be greatly appreciated.
> I need to get this functional so I can move toward full site testing of
> this system.
>
> Thanx
> Bruce Lundberg

I think that I've found the answer!! Our system is running on Solaris
with NIS handling the alias files in a slightly twisted fashion (don't
get me going on this). The /etc/nsswitch.conf file showed alias
resolution order as "nis files".

running a sendmail -bv under truss showed that the sendmail binary was
trying to open the aliases.db file over and over again for 10 minutes
until something finally resolved or failed and sendmail moved on.
Removing the residual aliases.db file from the original Solaris
sendmail install didn't , and neither did using NIS exclusively.
However when I copied the alaises file from the NIS-master, and ran
newalaises on it, the system started functioning immediately.

Most likely this was due to this new sendmail binary also having
updated compile options vs. the original sendmail binaries. We're
trying to set the stage for upgrades of other systems and the eventual
retirement of NIS. One of the other compile options that was upgraded
was the use of Berkely DB vs. gdb in the older version.

Ahhh live and learn!!

Bruce Lundberg