Hi.
It is Solaris 11 server. I have large number of message accumulated in /var/spool/mqueue. I ran "newaliases", but that didn't help. I can clear that directory but then new messages keeps dropping in it. Can someone suggest, what can I do to fix this ?
root@dbserv-ora1:/# svcs -a | grep mail
online 17:16:34 svc:/network/sendmail-client:default
online 17:16:34 svc:/network/smtp:sendmail
root@dbserv-ora1:/# ls -ltr /var/spool/mqueue | wc -l
101704
root@dbserv-ora1:/# cat /var/spool/mqueue/qf498GrTFF016475
V8
T1728407214
K1728433040
N32
P2917477
I0/23/50316
Malias database unavailable
Frs
$_localhost
$r
$slocalhost
${daemon_flags}
${if_addr}127.0.0.1
SMAILER-DAEMON
Malias database unavailable
Cpostmaster:1:0:postmaster
rRFC822; postmaster@dbserv-ora1.pre.ad.tetra.com
RPFA:root
H?P?Return-Path: <▒g>
H??Received: from localhost (localhost)
by dbserv-ora1.pre.ad.tetra.com (8.15.2+Sun/8.15.2) id 498GrTFF016475;
Tue, 8 Oct 2024 10:06:54 -0700 (PDT)
H?D?Date: Tue, 8 Oct 2024 10:06:54 -0700 (PDT)
H?F?From: Mail Delivery Subsystem <MAILER-DAEMON>
H?x?Full-Name: Mail Delivery Subsystem
H?M?Message-Id: <202410081706.498GrTFF016475@dbserv-ora1.pre.ad.tetra.com>
H??To: postmaster
H??MIME-Version: 1.0
H??Content-Type: multipart/report; report-type=delivery-status;
boundary="498GrTFF016475.1728407214/dbserv-ora1.pre.ad.tetra.com"
H??Subject: Postmaster notify: see transcript for details
H??Auto-Submitted: auto-generated (postmaster-notification)
.
root@dbserv-ora1:/#
What does the mail log show? -- N.B. Solaris might not have mail logging enabled by default.
What does sendmail -bp or mailq show?
The message you showed is a Delivery Status Notification (DSN) a.k.a. a bounce message. It's automatically generated in response to another email. And it looks like the offending mail that caused the bounce isn't included.
Mail logs will show -- if they are enabled -- the message that caused the generation of the DSN with the message ID 498GrTFF016475.
The 101704 number is actually (at least) double the number of messages in the /var/spool/mqueue directory as there are queue files and data files (I don't remember which is which, but it doesn't really matter). So the real count is more like 50852 messages in the mail queue. That's 50852 that haven't bounced yet. Meaning that's 50852 from the last seven days.
You need to see what the original messages are and if they are legitimate.
Based on the numbers, I'm guessing that these messages are of marginal value or you almost certainly have a very serious problem to have 50852 messages stuck in queue for multiple days. That sort of hang up in mail delivery will DEFINITELY be noticed by someone.
That sort of makes me wonder if something might have been compromised or using a vulnerability to send spam and many of these messages are spam or DSNs therefor.
N.B. I'm trusting that you're on the up and up and that you run your server to the best of your ability. As such, I'm assuming someone is doing something unauthorized / unsanctioned on your system.
I've never had a missing aliases database cause the symptoms that you're describing. -- I'm sure that the aliases database should be fixed, but I think it's likely a 2nd order problem when I'd be focused on the first order problem of where all the mail is coming from and going to.
I digged little more on this and got some more information. Three important are -
oracle use sent some alerts email to one email address. I checked "/var/spool/cron/crontabs/oracle" and there are few cron jobs there, which have scripts and they trigger email to our Exchange Inbox.
This server was authenticated via NIS and recently moved to AD authentication. If I see maillog, it mention "can't communicate with ypbind". Not sure if this is also an issue or can be just ignored. "oracle" is a local user.
root@dbserv-ora1:/# mailq | tail -20
<oracle@dbserv-ora1.tetra.com>
499IuCCc015966 262 Wed Oct 9 11:56 <oracle@dbserv-ora1.tetra.com>
(alias database unavailable)
<oracle@dbserv-ora1.tetra.com>
499IuCCY015966 262 Wed Oct 9 11:56 <oracle@dbserv-ora1.tetra.com>
(alias database unavailable)
<oracle@dbserv-ora1.tetra.com>
499IuCCU015966 262 Wed Oct 9 11:56 <oracle@dbserv-ora1.tetra.com>
(alias database unavailable)
<oracle@dbserv-ora1.tetra.com>
499Ij070012324 262 Wed Oct 9 11:45 <oracle@dbserv-ora1.tetra.com>
(alias database unavailable)
<oracle@dbserv-ora1.tetra.com>
499IuCCO015966 262 Wed Oct 9 11:56 <oracle@dbserv-ora1.tetra.com>
(alias database unavailable)
<oracle@dbserv-ora1.tetra.com>
499IuCCa015966 262 Wed Oct 9 11:56 <oracle@dbserv-ora1.tetra.com>
(alias database unavailable)
<oracle@dbserv-ora1.tetra.com>
Total requests: 491
root@dbserv-ora1:/#
root@dbserv-ora1:/# ls -ltr /var/spool/mqueue/ | tail -10
-rw------- 1 root smmsp 1029 Oct 12 00:11 qf499IuCCa015966
-rw------- 1 root smmsp 1029 Oct 12 00:11 qf499Ij070012324
-rw------- 1 root smmsp 1029 Oct 12 00:11 qf499IuCCY015966
-rw------- 1 root smmsp 1029 Oct 12 00:11 qf499IuCCU015966
-rw------- 1 root smmsp 1029 Oct 12 00:11 qf499IuCCc015966
-rw------- 1 root smmsp 1029 Oct 12 00:11 qf499IuCCW015966
-rw------- 1 root smmsp 1029 Oct 12 00:11 qf499IuCCQ015966
-rw------- 1 root smmsp 1029 Oct 12 00:11 qf499IuCCS015966
-rw------- 1 root smmsp 262 Oct 12 00:15 df49C7F4I4008889
-rw------- 1 root smmsp 1103 Oct 12 00:15 qf49C7F4I4008889
root@dbserv-ora1:/# cat /var/spool/mqueue/qf49C7F4I4008889
V8
T1728717305
K1728717305
N1
P30687
MCannot bind to map mail.aliases in domain pre.tetra.com: can't communicate with ypbind: No such file or directory
Fbs
$_localhost [127.0.0.1]
$rESMTP
$sdbserv-ora1.tetra.com
${daemon_flags}
${if_addr}127.0.0.1
S<oracle@dbserv-ora1.tetra.com>
A<>
Malias database unavailable
rRFC822; oracle@dbserv-ora1.tetra.com
RPFD:<oracle@dbserv-ora1.tetra.com>
H?P?Return-Path: <▒g>
H??Received: from dbserv-ora1.tetra.com (localhost [127.0.0.1])
by dbserv-ora1.tetra.com (8.15.2+Sun/8.15.2) with ESMTP id 49C7F4I4008889
for <oracle@dbserv-ora1.tetra.com>; Sat, 12 Oct 2024 00:15:05 -0700 (PDT)
H?x?Full-Name: Oracle
H??Received: (from oracle@localhost)
by dbserv-ora1.tetra.com (8.15.2+Sun/8.15.2/Submit) id 49C7F4HJ008791
for oracle; Sat, 12 Oct 2024 00:15:04 -0700 (PDT)
H??Date: Sat, 12 Oct 2024 00:15:04 -0700 (PDT)
H??From: Oracle <oracle@dbserv-ora1.tetra.com>
H??Message-Id: <202410120715.49C7F4HJ008791@dbserv-ora1.tetra.com>
H??To: oracle@dbserv-ora1.tetra.com
H??Subject: Output from "cron" command
H??MIME-Version: 1.0
H??Content-Type: text/plain
.
root@dbserv-ora1:/#
The ls -ld output shows that the newalias command correctly rebuilds the aliases.db
This can be an issue.
Delete a nis word in the aliases line in /etc/nsswitch.conf. Ensure the first word is file (that means the /etc/mail/aliases.db). It can make sense to delete nis words in other lines, too.
Delete a reference to nis or yp in the /etc/mail/sendmail.cf and /etc/mail/submit.cf files, especially in the line that mentions the aliases
After a change in these files restart the sendmail service.
Have the emails stopped reaching your Exchange Inbox since migrating from NIS to AD?
I speculate that:
NIS was providing a central alias database.
Email to the Exchange mailbox has stopped since the migration from NIS to AD
Older emails in the Exchange mailbox (if you still have them) were from oracle@dbserv-ora1.tetra.com and to oracle@dbserv-ora1.tetra.com.
Yes, I believe the can't communicate with ypbind is a telling message. Specifically Sendmail can't access the alias database which -- I believe -- was served up by NIS via ypbind -- in addition to authentication.
I speculate that the oracle user had an alias that caused messages to be forwarded to the Exchange mailbox.
Without the NIS based alias table to specify the Exchange mailbox to forward messages for the oracle user to, the messages would try to deliver locally but are running into an error and thus generating a bounce. But the bounce can't be delivered, so you're probably ending up with double bounces (a bounce of a bounce).
Is the NIS server still available?
Can you log into the NIS server and check the aliases table which is compiled into the alias database?
After removing "nis" from /etc/nsswitch.conf and clearing /var/spool/mqueue, it is all good. I waited for one day and still there are no mail accumulated in mailq. Thanks for the help and suggestions.
If you still get (too) many Postmaster mails, usually aliased to root, they now accumulate in the /var/mail/root mailbox.
Frequent mails to root can mean a problem.
It makes sense to read them, and do some root-cause analysis.
Of course it's easy to truncate or delete the mailbox.
BTW I once wrote a Nagios plugin that reports file queues in /var (not only /var/mail/mqueue).
It can be run standalone on the command line.