| The mailq (same as sendmail “bp ) command will show email that has not been able to be delivered yet (for whatever reason):
root@hpeos004[] mailq /var/spool/mqueue (1 request) ----Q-ID---- --Size-- -----Q-Time----- ------------Sender/Recipient------------ h9ODW2n03157 33 Fri Oct 24 14:32 fred (Deferred: Connection refused by hpeos003.hq.maabof.com.) barney@hpeos002 root@hpeos004[]
In this case, I am looking at the mail queue on one of my mail clients I configured in the NFS mail cluster earlier. The reason the mail was not delivered was because the mail hub has been taken down for some reason. When the mail hub comes back online, what will happen? Well, in our situation where we have mail clients , we don't have a sendmail daemon running continuously hence the deferred email will sit there until someone else sends an email. At that time, a sendmail daemon will be spawned and pick up the new and any deferred email still in the mail queue. If no one sends an email, an unsent email will just sit there. Where we don't have a sendmail daemon running, it might be an idea to set up a cron job that runs a sendmail “q command. Without a time specified, the sendmail “q command will process the mail queue immediately:
root@hpeos004[] sendmail -q root@hpeos004[] mailq /var/spool/mqueue is empty root@hpeos004[]
In fact, some mail administrators would argue that in most cases you could stop sendmail running as a daemon on the mail hub (not having a daemon for hackers to attack), but have cron periodically run sendmail “q to process the mail queue. I don't have a problem with that. 19.7.1 Files in the mail queue When an email is being processed , there will be a number of files in the /var/spool/mqueue directory. Here's an example:
root@hpeos004[] mailq /var/spool/mqueue (1 request) ----Q-ID---- --Size-- -----Q-Time----- ------------Sender/Recipient---------- h9ODmco03268 33 Fri Oct 24 14:48 fred (Deferred: Connection refused by hpeos003.hq.maabof.com.) barney@hpeos002 root@hpeos004[] root@hpeos004[mail] cd /var/spool/mqueue/ root@hpeos004[mqueue] ll total 4 -rw------- 1 root mail 33 Oct 24 14:48 dfh9ODmco03268 -rw------- 1 root mail 494 Oct 24 14:48 qfh9ODmco03268 root@hpeos004[mqueue]
The df file is the body of the email. Morally, I don't think we should edit or look at these files. The qf file is a job control file, which includes the message header. This might give us some idea of what's wrong with the email:
root@hpeos004[mqueue] cat qfh9ODmco03268 V4 T 1067003318 K1067003318 N1 P120033 I64/8/12311 M Deferred: Connection refused by hpeos003.hq.maabof.com. $_fred@localhost S fred Afred@hpeos004.maabof.com RPFD:barney@hpeos002 H?P?Return-Path: <g> H??Received: (from fred@localhost) by hpeos004.maabof.com (8.11.1 (Revision 1.5) /8.9.3) id h9ODmco03268 for barney@hpeos002; Fri, 24 Oct 2003 14:48:38 +0100 (BST) H?D?Date: Fri, 24 Oct 2003 14:48:38 +0100 (BST) H?F?From: fred H?M?Message-Id: <200310241348.h9ODmco03268@hpeos004.maabof.com> . root@hpeos004[mqueue]
I have highlighted some areas of interest: the creation time (seconds since Thursday, January 1, 1970), the status of the message, and the sender. Each message can generate the following types of files in the mail queue directory ( /var/spool/mqueue ), where XXnnnn is the message ID: | | dfXXnnnnn | Data file (message body) | | | qfXXnnnnn | Job control file (job processing information, including header) | | | lfXXnnnnn | Lock file (job synchronizer; exists if job is being processed) | | | nfXXnnnnn | Job creation file (exists while message ID is being created) | | | tfXXnnnnn | Temporary file (image of qf file, used during a queue rebuild) | | | xfXXnnnnn | Transcript file (contains a record of the job) |
The base file name is constructed as follows : Where: Deleting a set of files in the mqueue directory effectively deletes an email. 19.7.2 Monitor sendmail 's logfile The sendmail logfile is /var/adm/syslog/mail.log . Logging occurs via a syslog message of the mail facility. The logging level used by default is LogLevel=9 :
root@hpeos003[mail] pwd /etc/mail root@hpeos003[mail] more sendmail.cf ... # Logging Level (option LogLevel): # # # # Logging level determines the classes of events which will be # # logged by sendmail in /var/adm/syslog/mail.log. By default the # # log level is 9, which reports successful deliveries (and the # # mailer and host used for delivery), queue daemon startup, alias # # database rebuilds, and various errors. More detailed information # # is reported with higher log levels. In particular, log level 11 # # reports the MX host (if any) and internet address to which mail # # was delivered. Refer to the documentation for details. # # # # Note that log level also affects the information reported by # # sendmail -bv. At log level 10 and higher, sendmail also reports # # the mailer and host that would be used for addresses that are # # "deliverable." # # # # This option is defined on the line beginning: # # # # O LogLevel= # ... # log level O LogLevel=9 ... root@hpeos003[mail]
As can be seen from the text, if you increase the logging level to 11 , you will get detailed information regarding IP addresses from DNS records. This can be useful if you suspect that DNS MX records are causing problems. 19.7 3 Mail statistics You can get sendmail to gather statistics on the quantity of emails it sends and receives. We simply create a file called sendmail.st in the /etc/mail directory. This is the default name for the status file. We can check this in the sendmail.cf file:
root@hpeos003[mail] more sendmail.cf ... # status file O StatusFile=/etc/mail/sendmail.st # time zone handling: # if undefined, use system default # if defined but null, use TZ envariable passed in # if defined and non-null, use that info O TimeZoneSpec= ... root@hpeos003[mail]
We should set the permissions so the root is the only user with access:
root@hpeos003[mail] pwd /etc/mail root@hpeos003[mail] root@hpeos003[mail] touch sendmail.st root@hpeos003[mail] chmod 600 sendmail.st
Over time, data will accumulate as to which mailers sendmail used to process emails. To analyze the data, we can use the mailstats command:
root@hpeos003[mail] mailstats Statistics from Fri Oct 24 15:22:41 2003 M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis Mailer 3 27 108K 27 105K 0 0 local ============================================================= T 27 108K 27 105K 0 0 C 27 27 0 root@hpeos003[mail]
The types of mailers listed on the left side under the M column can be extracted from the sendmail.cf file:
root@hpeos003[mail] grep ^M sendmail.cf Mlocal, P=/usr/bin/rmail, F=lsDFMAw5:/@qm9, S=10/30, R=20/40, Mprog, P=/usr/bin/sh, F=lsDFMoqeu9, S=10/30, R=20/40, D=$z:/, Msmtp, P=[IPC], F=mDFMuX, S=11/31, R=21, E=\r\n, L=990, Mesmtp, P=[IPC], F=mDFMuXa, S=11/31, R=21, E=\r\n, L=990, Msmtp8, P=[IPC], F=mDFMuX8, S=11/31, R=21, E=\r\n, L=990, Mrelay, P=[IPC], F=mDFMuXa8, S=11/31, R=61, E=\r\n, L=2040, Mx400, P=/opt/x400/lbin/x4mailer, F=CDMFmn, S=14, R=24, A=x4mailer -f $g $u Mopenmail, P=/opt/openmail/bin/unix.in, F=DFLMXmnu, E=\n, S=15, R=25, A=unix.in Momxport, P=/opt/openmail/bin/xport.in, F=LMn, A=xport.in $u Muucp, P=/usr/bin/uux, F=DFMhuUd, S=12, R=22/42, M=100000, Muucp-old, P=/usr/bin/uux, F=DFMhuUd, S=12, R=22/42, M=100000, Msuucp, P=/usr/bin/uux, F=mDFMhuUd, S=12, R=22/42, M=100000, Muucp-new, P=/usr/bin/uux, F=mDFMhuUd, S=12, R=22/42, M=100000, Muucp-dom, P=/usr/bin/uux, F=mDFMhud, S=52/31, R=21, M=100000, Muucp-uudom, P=/usr/bin/uux, F=mDFMhud, S=72/31, R=21, M=100000, root@hpeos003[mail]
Mailer 3 happens to be SMTP. To clear the statistics, we should zero-length the file by copying /dev/null to it. Happy reading. |
