We have two internal servers running linux. One is our mail server running RedHat 7.3, and has been working fine for years, sending and receiving email internally and externally. The other is a file server running Red Hat Enterprise Linux ES release 4 (Nahant Update 3).

We want to be able to have applications on the file server send emails to users on the mail server. For now we are just using the mail command to test. All attempts result in timeout messages in the file server maillog.

For example, I send a test email to bill@foo.com. The file server maillog says that the message is accepted for delivery, but then after a minute it says:

stat=Deferred: Connection timed out with mailserver.foo.com

On the mail server side, we see the error:

NOQUEUE: fileserver.foo.com [x.x.x.x] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

I have spent a few hours googling the latter error, but no joy yet. Can anyone shed some light?

Thanks,
Bill

The message on the mail server looks like what you get when setting up a mail client and you hit "check available authentication mechanisms". The file server looks like it found the mail server OK (DNS MX records OK etc.) and it looks like the file server managed to send HELO/EHLO, then just stopped. Could it be authentication? Something in the mail server access.db? Reverse lookup on the file server IP? Might be worth a tcpdump mission to look at the actual conversation and try to home in on the problem.

By money would be on a DNS issue. Something like the mail server not being able to resolve the IP address of the file server before the file server sendmail times out and drops the connection. Which DNS server will the mail server query, and will it have both forward and reverse records for the file server? Other clients are probably already catered for with dynamic DNS over DHCP or the like but the file server is probably a static IP that has never needed a reverse, PTR record until now. Try a 'dig -x x.x.x.x' on the mail server for the file server IP to see if it gets the right result or times out.

Happy huntin'

--DaveG

Hi Dave,

The mailserver's access.db is pretty simple:

localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY

According to the mailserver's nsswitch.conf, the /etc/hosts file should be used first for name resolution:

hosts: files dns

Our /etc/hosts has an entry for the fileserver:

x.x.x.x fileserver.foo.com fileserver

so I would think reverse lookup would have no trouble. I tried a ping from the mailserver to fileserver.foo.com and it connected instantly and worked fine.

Certainly if the mailserver were to rely on DNS to find fileserver.foo.com it would fail - the world doesn't know about our fileserver - I'm sure no reverse PTR records exist out there.

The dig -x x.x.x.x came back instantly:

# dig -x x.x.x.x

; <<>> DiG 9.2.1 <<>> -x x.x.x.x
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34862
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;x.x.x.x.in-addr.arpa. IN PTR

;; Query time: 159 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 27 11:24:01 2006
;; MSG SIZE rcvd: 45

That SERVFAIL status and ANSWER: 0 seem to suggest that DNS failed, but again not sure why DNS is involved. Our mailserver is configured as a DNS server (so MAPS RBL+ will work) - perhaps I need to configure it to know about the fileserver - but again don't see why.

I'm probably betraying my relative newbieness to sendmail and DNS

Thanks for taking the time to think about my problem.

Bill

I was able to get a message through, but I had to cripple my mailserver to do it

The problem seems to be with our oddball network configuration.

Our interface with the outside world is a little unusual:

Cisco Router ->

Mikrotik Router ->

Subnet with mailserver
Subnet with fileserver

The computer with the Mikrotik software router has three NICs - one to the Cisco, one to the mailserver, and one to the fileserver and the rest of our internal network.

The Mikrotik router has a NAT rule to change the IP address by which the world knows our mailserver (e.g., A.B.C.D) to the address by which our internal network knows it (10.10.10.1). There is no similar NAT rule for traffic originating in the internal network.

When the fileserver sends an email to bill@foo.com, I want it to be smart enough to send it to bill@10.10.10.1. However, it tries to send it to bill@A.B.C.D. I cannot traceroute A.B.C.D from my fileserver - it hangs at the Cisco Router. I am not sure why, but I think it has to do with my NAT rules.

I temporarily added two NAT rules to the Mikrotik so that packets originating in the internal network and addressed to A.B.C.D are NAT'd to 10.10.10.1, and packets from the mailserver to the internal network are NAT'd from 10.10.10.1 to A.B.C.D. I was able to send the email (yay!), but it of course broke every computer that tried to connect to the mailserver using 10.10.10.1. The mailserver's NAT'd response would say it was A.B.C.D when PC was expecting 10.10.10.1, and connection could not be established.


So I seem to have two approaches for fixing the problem. (1) get my fileserver to resolve foo.com as 10.10.10.1, or (2) change all hundred-odd computers on my internal network to POP3 over using mailhost of A.B.C.D instead of 10.10.10.1.

Not sure if (1) is possible, but it sure looks easier.

Thanks again if you got this far
Bill

A few other things...

My /etc/host.conf is order hosts,bind

My fileserver's /etc/hosts file has my mailserver defined:

10.10.10.1 mailserver.foo.com mailserver mailhost

nslookup apparently goes straight to DNS for the info, bypassing /etc/hosts:

nslookup mailserver.foo.com
Server: x.x.x.x
Address: x.x.x.x#y

Non-authoritative answer:
Name: mailserver.foo.com
Address: A.B.C.D

My reading suggests that sendmail resolves names by doing a gethostbyname(), which should use /etc/nsswitch.conf to decide how to go about it. On my fileserver, it should check /etc/hosts before going to DNS. I don't know why sendmail insists on trying to send to A.B.C.D instead of 10.10.10.1 as my /etc/hosts file has said.

Ok I am going to stop posting for awhile

Thanks,
Bill

Hah! I figured it out!!

Added these lines to my mailertable

.foo.com smtp:[10.10.10.1]
foo.com smtp:[10.10.10.1]

and rebuilt mailertable.db with

makemap hash mailertable.db <mailertable


This apparently bypasses sendmail's hunger for MX records.

http://linuxgazette.net/issue31/tag_maildns.html was the link that led me to mailertables and my solution.

Thanks again,
Bill

Just checked my e-mail...

Er, looks like you figured that one out all by yourself. Glad to be of any help whatsoever, if any, no problem. I think I can follow what happened - NAT, DNS, sendmail looking for MX records, no reverse records in /etc/hosts. Solution - mailertable. The only other option I can think of would be to add MX and PTR records to the DNS server, but that needs to be maintained, DHCP fixed hosts, etc. ... If it works, why tinker?

All the best,

--DaveG

Thanks Dave - your ideas helped direct me to the solution.

Bill