Sendmail 8.7.6 hostname lookup failure

[Dimitry Snezhkov]

Forum,

I am a little confused with
my sendmail configuration.

my host is host1.domain1.com
my client PC is on .domain2.com
I have set up relaying through
host-relay.domain1.com via
DS parameter in sendmail.cf
sendmail -v user1.domain2.com
yields:
user1@domain2.com... Deferred: Name server: host-relay.domain1.com: host name lookup failure.

I have checked DNS . I can resolve host-relay both ways.
I can also send mail from user1@domain2.com( my EXCHANGE account ) to user2@host1.domain1.com ( UNIX account ) no problem.

Where do I fail?

In DNS I have
2 MX records one for domain1.com, the other for domain2.com both relaying through host-relay.domain1.com. For other HP-UX boxes the configuration is the same and they work fine. This one is a new RP7400
.

I am not familiar with NT side of relaying. Does the admin need to specify my new host1 in their NT relay list or something , or this is my config. problem.

I would really appreciate your help.

Thanks, Dimitry

[Christopher Caldwell]

I don't think you need to use the DS macro if the host your on is the relay.

By default, sendmail by default doesn't use the MX if the address is considered "local".

From host one (the relay) send us the output of nslookup host2. When you get the IP of host2, send us the output of nslookup IP.of.host.2

[Kofi ARTHIABAH]

You might want to verify that your /etc/nsswitch.conf is set up to go to DNS and that your /etc/resolv.conf is same on the other boxes that work.

It appears that your HPUX server is not able to do name lookups for MX records... because it cannot find a suitable resolver?

good luck.

your /etc/nsswitch.conf should read something like:

hosts: files [NOTFOUND=continue] dns

as a precaution also check your /etc/mail/sendmail.cw - it should contain only localhost

[Dimitry Snezhkov]

I appologize for unclear explanation , but this is how it looks :

UNIX( host1.domain1.com )
|
|
NT( host-relay.domain1.com : Also responsible for domain2.com)
|
|
Exchange Mailbox

if I get rid of DS , I get:
user@domain2.com... Connecting to mail.domain2.com. via smtp...
and Times out .

mail.domain.com is different than Exchange Server ( host-relay.domain1.com )

I think , it figures out mail.domain2.com from MX records

[Dimitry Snezhkov]

I do have :
hosts: files [NOTFOUND=continue] dns in nsswitch.conf and localhost is insendmail.cw there as well.

[Uday_S_Ankolekar]

Hi,

What is your resolv.conf in /etc/directory shows?? Is it pointing to proper name server and domain??
Secondly what you get when running nslookup with domain1.server and domain2.server?
command :nslookup hostname
-USA...

[Kofi ARTHIABAH]

just for a laugh - could you try putting an entry in your /etc/hosts file for host-relay.domain1.com?

it does sound like a name lookup issue -if this works then it means that your DNS servers may actually be to blame.

cheers

[Christopher Caldwell]

On the Unix host:

# nslookup
>set type=MX
>domain2.com
domain2.com preference = 10, mail exchanger = nt.host.com
BLAH
BLAH
nt.host.com A.B.C.D
>exit
#telnet A.B.C.D 25


If you don't get A.B.C.D you've got a name resolution problem.

If you can't telnet A.B.C.D 25, an SMTP server isn't running on the NT host.

[Dimitry Snezhkov]

I don't understand why, but maybe, you can explain.

When DShost-relay in an unqualified server name , I can send mail!!! If host-relay.domain1.com, I cannot!!!

I have done nslookup on host-relay.domain1.com --> it's fine, so is nslookup on relay,

It seemed to fix the problem. I am confused. I understand that /etc/resolv.conf has search directive for domain1.com. Whay would it behave differently w/FQDN ??

[Christopher Caldwell]

Dunno. You might be missing a . somewhere in DNS, or you may still be having someother resolution problem.

This best thing to do on these is to make sure you look up everything both ways -- frontwards by name and reverse by IP - (qualified [a.com], fully qualified [a.com.], and unqualified [a]). Pay careful attention to where DNS gets the name (server vs. files).

Don't forget to check the MX.

When you do that, you'll usually find that something is misconfigured.