Outgoing mail to smtp relay failure

[Rcky Mntere]

HPUX 11.31 Itanium server
Not a mail expert...

We have configured two relays: mailouta and mailoutb, both smtp relays to our exchange server.

We use mail for notifications of system and network failure (page and email). We had a situation where an outage occured but the mail system on the HP-UX server, failed to send the message. All scripts executed correctly with no errors (they are designed to capture errors if there is a problem with the mailx phase).

No errors were reported in the syslog.log or mail.log files. Nothing showed up in the exchange logs either. So we concluded that the mail system on the HPUX server stopped, for 8 hours. it only resumed after weekly maintenance system reboot.

Any suggestions as to how to troubleshoot this. I ran a test and stopped the sendmail process and mail FROM the server was sent to the exhange server, so sendmail daemon is not the failure, I think.

[Steven Schweda]

> We have configured two relays: mailouta and
> mailoutb, [...]

These are HP-UX systems? You "have
configured" them how, exactly?

> We use mail for notifications of system
> and network failure (page and email).

How does a system which is suffering a
system or network failure arrange to send an
e-mail message to report its problem?

> [...] the mail system on the HP-UX server,
> [...]

Which "the mail system" on which "the HP-UX
server"?

> All scripts executed correctly [...]

You know this how, exactly?

> No errors were reported in the syslog.log
> or mail.log files.

Which "the [...] files", where?

It might be interesting to see exactly how
one of the "All scripts" actually sends an
e-mail message.

[Rcky Mntere]

The System Sending mail is HPUX 11.31 itanium. Call it HPUX-A, the systems being monitored HPUX-N, the mail relays, both windows: RELAY-A or RELAY-B.

The smtp relays are windows servers.
They are configured as MX records in DNS:
nslookup -query=MX dpsk12.org
Using /etc/hosts on: pluto

looking up FILES
Trying DNS
mydomain.org preference = 10, mail exchanger = relay-a.mydomain.org
mydomain.org preference = 10, mail exchanger = relay-b.mydomain.org

Data Truncated.

The script runing on the HPUX-A system does the following:
echo "MESSAGE TEXT
" | mailx -s "$message_text @ $date_received-$time_received" $MAIL
if [ $? -ne 0 ] ; then
echo "unexpected problems with mailx" >> $LOGFILE 1>&2
exit 1


The $LOGFILE shows no errors, so I know the mailx command in the script exited with value 0.

The HPUX-A system is monitoring other HPUX-1|2|3 etc. systems, hence if the monitor shows a failure, the HPUX-A system, executes a notification script, sending a message to user@mydomain.org (which is an exchange mail box).

I reviewed both syslog.log and mail.log files on HPUX-A and NO MAIL was sent between 08:31 and 16:41 on the day of the failure (there were no entries in the mail.log file or anything associated with a mail failure in syslog.log). We would normally see mail during this time frame as other cron jobs run and send mail as well.

Excerpt from mail.log file at 08:30 and 16:40. Note, this is a complete series of messages between these times, only the content was modified for security reasons

Sep 12 08:30:03 HPUX-A sm-mta[12462]: o8CEU2xQ012459: to=, ctladdr= (0/3), delay=00:00:01, xdelay=00:00:00, mailer=esmtp, pri=123013, relay=XXXmailout01a.mydomain.org. [164.
92.10.173], dsn=2.0.0, stat=Sent (Requested mail action okay, completed)
Sep 12 08:30:03 HPUX-A sm-mta[12463]: sm_gethostbyname:name :localhost family:2
Sep 12 08:30:03 HPUX-A sm-mta[12463]: o8CEU3i7012463: from=, size=10798, class=0, nrcpts
=1, msgid=<201009121430.o8CEU3i7012463@HPUX-A.mydomain.org>, proto=SMTP, daemon=MTA, relay=root@localhost [127.0.
0.1]
Sep 12 08:30:03 HPUX-A sm-mta[12467]: sm_gethostbyname:name :XXXmailout01a.mydomain.org. family:22
Sep 12 08:30:03 HPUX-A sm-mta[12467]: o8CEU3i7012463: to=, ctladdr= (0/3), delay=00:00:00, xdelay=00:00:00, mailer=esmtp, pri=130798, relay=XXXmailout01a.mydomain.org. [164.
92.10.173], dsn=2.0.0, stat=Sent (Requested mail action okay, completed)
Sep 12 18:40:03 HPUX-A sendmail[1458]: sm_gethostbyname:name :HPUX-A family:22
Sep 12 18:40:03 HPUX-A sendmail[1458]: o8D0e3uG001458: from=root, size=407, class=0, nrcpts=1, msgid=<201009130
040.o8D0e3uG001458@HPUX-A.mydomain.org>, relay=root@localhost
Sep 12 18:40:03 HPUX-A sendmail[1465]: sm_gethostbyname:name :XXXmailout01a.mydomain.org. family:22
Sep 12 18:40:03 HPUX-A sendmail[1465]: o8D0e3uG001458: to=sb@mydomain.org, ctladdr=root (0/3), delay=
00:00:00, xdelay=00:00:00, mailer=esmtp, pri=120407, relay=XXXmailout01a.mydomain.org. [164.92.10.173], dsn=2.0.
0, stat=Sent (Requested mail action okay, completed)

[Bill Hassell]

Use sendmail -v to trace the actual operations:

sendmail -v myname@mymail.com < /etc/issue

This will show you most of the steps in handshaking with the mail relay. It may show that it's not going where you want or it is being rejected. The mail.log is not always the most useful tool in troubleshooting mail problems.

[Rcky Mntere]

>Use sendmail -v to trace the actual operations:

>sendmail -v myname@mymail.com < /etc/issue

I have used this before but was hoping for some methodology to use to troubleshoot the "suspension" of mail when it occurred or to at least be able to identify the problem when the notification script(s) send mail.

We are looking at an external troubleshooting method that would be checking the presence of a file at an exchange mailbox every 30 minutes (sent from the HPUX-A system) and if the file is NOT present, the external monitor script would then send a notification (from a completely different system). Not the best approach but it would alert us if the HPUX-A system failed to send mail.

[Jim Walls]

You could poll the HP-UX server and periodically check the mail queue. If the queue starts growing it might indicate summat has stopped.

Thi could also be caused by something external to the HP-UX server - a network glitch, for example - a poller might pick that up also.

[Steven E. Protter]

Shalom,

Basic process:
1) On smtp relay explicitly permit relay from this host by IP address.
2) Change DS parameter in sendmailcf to indicate the smart relay host. I recommend this even if you don't run the sendmail deamon.
3) sendmail -v -q
# This runs queue runner, provides nice diagnostics.

SEP