Showing results for 
Search instead for 
Did you mean: 

Mail not delivering

Go to solution
John Peace
Frequent Advisor

Mail not delivering

None of the domain names below are real . They were changed to protect the innocent. The messages are all correct.

I am having problems getting external domain mail to deliver from my HP. My domain is All mail addressed to anybody inside works. Any mail addressed outside fails.

This is an example of an error in mail.log

Feb 5 15:54:02 Mast01 sendmail[11979]: PAA11977:, ctladdr=root (0/3), delay=00:00:00, xdelay=00:00:00, mailer=smtp, [], stat=Deferred: Connection reset by

When I use verbose mode I get the following:

# sendmail -v
This is a test Connecting to via smtp... Connecting to via smtp... Closing connection to Deferred: Connection reset by
Closing connection to

#mailq -v

PAA11977 52 120052 Feb 5 15:54 root
( reply: read error from

I do not have the sendmail daemon running. I am running my HP as a client only. My questions?

Is this a firewall problem? Is it on my end or the distant end? What else can I do to troubleshoot this? I am not the firewall or network administrator.
Mark Greene_1
Honored Contributor

Re: Mail not delivering

Can you ping eitehr relay2 or relay5 from the HP box? What do you get if you telnet to either relay system to port 25?

You may need to enable domain masquerading on the HP system if you external mailer is not pointing back to your internal hosts and is configured to send to only known systems.

the future will be a lot like now, only later
John Peace
Frequent Advisor

Re: Mail not delivering

Ping and traceroute are restricted through our firewall. I tried to telnet port25 to the host and got:

Connected to
Escape character is '^]'.
Connection closed by foreign host.
Steven E. Protter
Exalted Contributor

Re: Mail not delivering

I have had your problem.

in /etc/ (it might be in /etc/mail

you have a DS paramter, for relaying mail

[IP address of mail relay server]

Your problem is your mail relay server is not permitting you to relay mail.

If you control it, configure it to accept mail for relay from your HP-UX box. If not see the mail relay servers admin and get her or him to do it.

Let's say you aren't using a mail relay server.

Different issues. In that case you need to resolve the hostname of the server that is supposed to accept your mail. If its an internal exchange box, you really still have a mail relay issue.

If you are supposed to route your own mail to the Internet look at this:


He should point to an internal DNS sever that will provide host resolution so that your sendmail daemon knows where the heck to send your mail.

/etc/nsswithc.conf handles how resolution and such happens. Should look kind of like this:
hosts: dns[notfound=continue unavail=continue tryagain=continue] files

This means DNS first....

Even behind a firewall, to properly route mail you need somebody to handle host resolution for you.

Additional diagnostics:

mailq - displays mail queued to go out.
sendmail -q tries to force immediate delivery of the mail queue

/usr/sbin/sendmail -v -d8.99 -d38.99

Just gets you even more verbose diagnistics, case you need it.

Good Luck.

This can be fixed.

Bet you didn't expect this much of a mouthful.

Steven E Protter
Owner of ISN Corporation
John Peace
Frequent Advisor

Re: Mail not delivering

My resolv.conf is pointing to our DNS. I had the DS macro configured for 1 week and all the mail left the HP and stuck at the smtp server. My network people are looking at that Whenever they don't have something they think is more important.. I was hoping to be able to bypass them and get it to go.

This is my latest try.

sendmail -v -d8.99 -d38.99
seq_map_parse(aliases.files, )
map_init(sequence:aliases.files, NULL, 0)
sequence:aliases.files NULL: valid
map_init(implicit:Alias0, /etc/mail/aliases, 0)
impl_map_open(Alias0, /etc/mail/aliases, 0)
hash_map_open(Alias0, /etc/mail/aliases, 0)
impl_map_lookup(Alias0, @)
db_map_lookup(Alias0, @)
implicit:Alias0 /etc/mail/aliases: valid
map_init(host:host, NULL, 0)
host:host NULL: valid
map_init(switch:aliases, aliases, 0)
switch_map_open(aliases, aliases, 0)
switch_map_find => 1
map_stack[0] = sequence:aliases.files
switch:aliases aliases: valid
map_init(dequote:dequote, NULL, 0)
dequote:dequote NULL: valid
getcanonname(, trying dns
dns_getcanonname(, trymx=1)
dns_getcanonname: trying (ANY)
dns_getcanonname: trying (A)
NO: errno=2, h_errno=4
dns_getcanonname: trying (MX)
getcanonname(, found
getmxrr(, droplocalhost=1) Connecting to via smtp... Connecting to via smtp... Closing connection to Deferred: Connection reset by
Closing connection to
Honored Contributor

Re: Mail not delivering

Does your firewall has any blocks for SMTP packets ??


Good Luck..
Mark Greene_1
Honored Contributor

Re: Mail not delivering


Are you sure the smtp client is running on your relay servers? When you do the telnet to either of them (be sure to specify port 25), you should get a connection string from the smtp client that looks something like this:

220 ESMTP Sendmail Switch-2.1.1/Switch-2.1.1; Thu, 06 Feb 2003 14:40:02 -0500
the future will be a lot like now, only later
Kasper Haitsma
Trusted Contributor

Re: Mail not delivering

Hi John,

I am curious to your DM (masquerade) setting. I think the remote systems relay[2|5] drop your connection, because they cannot do a reverse lookup of your hp-ux box. This is valid for both a direct connection from you to the internet, as well as an internal (to relay. Meaning: The messages are stuck on your companies relay for that same reason. Since you do not have the daemon running on your box, once the message is queued on your box, it stays there (untill you retry with 'sendmail -q[v]'). So I think you need to set the DM parm to, and the Reply-To in the message you send, to or appropriate. Bottom line, the domains (DM and Reply-To) should be resolvable from the other end (nslookup -q=mx should return host/IP pair[s])

It depends
W.C. Epperson
Trusted Contributor

Re: Mail not delivering

We've seen this sort of behavior in the past based on the timeout.ident in Sometimes the other server is not running an identd and your timeout.ident is greater than a timeout on their end. While you're waiting on the ident response, they decide you're not going to do an SMTP transaction and issue a RST.

You can also get some oddities when your sendmail is behind a proxy firewall. When the proxy accepts the connection request on behalf of the remote mail hub, yours thinks it's actually connected to the remote, which may not be available. You get the appearance that you're connecting to an SMTP server, but you're not, and the proxy eventually times out the connection and you log it as though it were the remote hub.
"I have great faith in fools; self-confidence, my friends call it." --Poe
John Peace
Frequent Advisor

Re: Mail not delivering

I will assign points. I am currently working this issue with my firewall people. All the suggestions are great.
Bill Hassell
Honored Contributor

Re: Mail not delivering

It all looks OK until the SMTP connection is attempted and the symptom definitely looks like a firewall issue. Opening port 25, whether telnet or SMTP seems to be blocked. The only difficulty is determining whether relay2 is closing it or the firewall.

Bill Hassell, sysadmin
W.C. Epperson
Trusted Contributor

Re: Mail not delivering

I agree with Bill that it "smells" mostly like a firewall problem. One generic issue that we see a lot is the following:

--Inside SMTP hub tries connection to outside SMTP hub on 25/TCP.
--Proxy server accepts the TCP connection for the outside SMTP hub's IP address because it's configured to proxy 25/TCP at the inside interface.
--Proxy server fails to proxy the connection through to the outside SMTP server, either because it is not configured to proxy 25/TCP through the outside interface or because the outside SMTP server can't be contacted.
--Both sides sit there until one times out.
--The inside SMTP server confuses the layer 4 TCP connection with a layer 7 SMTP connection ("200 OK") and logs that the outside mail server closed the connection. In this case, it probably will not use a second or subsequent MX record because it believes it made contact with the first outside server.
"I have great faith in fools; self-confidence, my friends call it." --Poe