See to=< messages not accepted by remote host:
$ sudo tail -f /var/adm/all.log|grep 'to=<.*PLMN.*'|grep -v 'stat=Sent'Count number of mails in queue (takes both d* and q*!) (when 'mailq' is too slow):
$ sudo ls /var/spool/mqueue | wc -l
Specific queue flushing:
/usr/lib/sendmail -q &
This is fine, but you wind up hanging on those other lame entries in the queue there because the mail server is offline, doesn't exist, didn't have its coffee, etc. The timeouts on these things will kill you and you never know where they'll appear during your flush. This means no immediate gratification, which was the whole point of the exercise. Instead you can tell sendmail to only flush certain items from the queue with an additional argument to -q. So you can do:
$ sudo /usr/lib/sendmail -qR cwinters.com -v
To only process entries in the queue with a recipient having 'cwinters.com' in it. Sweet! You can also use -qS to match on the sender and -qI to match on the queue ID.
You may also place an ! before the I or R or S to indicate that jobs are limited to not including a particular queue identifier, recipient or sender. For example, "-q!Rseattle" limits the queue run to jobs that do not have the string "seattle" somewhere in one of the recipient addresses. Should you need to terminate the queue jobs currently active then a SIGTERM to the parent of the process (or processes) will cleanly stop the jobs.
This apparently doesn't work with Sendmail 8.11.7p1+Sun.
Flushing a specific queue:
In some cases, you may find that a major host going down for a couple of days may create a prohibitively large queue. This will result in sendmail spending an inordinate amount of time sorting the queue. This situation can be fixed by moving the queue to a temporary place and creating a new queue. The old queue can be run later when the offending host returns to service. To do this, it is acceptable to move the entire queue directory:
$ cd /var/spool $ sudo mv mqueue omqueue; mkdir mqueue; chmod 0700 mqueue
You should then kill the existing daemon (since it will still be processing in the old queue directory) and create a new daemon. To run the old mail queue, issue the following command:
$ sudo /usr/lib/sendmail -C /etc/mail/queue.cf -q
The -C flag specifies an alternate configuration file queue.cf which should refer to the moved queue directory 'O QueueDirectory=/var/spool/omqueue' and the -q flag says to just run every job in the queue.
You can also specify the moved queue directory on the command line
$ sudo /usr/lib/sendmail -oQ/var/spool/omqueue -q
but this requires that you do not have queue groups in the configuration file, because those are not subdirectories of the moved directory. See the section about "Queue Group Declaration" for details; you most likely need a different configuration file to correctly deal with this problem. However, a proper configuration of queue groups should avoid filling up queue directories, so you shouldn't run into this problem. If you have a tendency toward voyeurism, you can use the -v flag to watch what is going on. When the queue is finally emptied, you can remove the directory:
$ sudo rmdir /var/spool/omqueue
If you flush the queue more than 5 days after the the mqueue directory was moved away, you need to specify the timeout value to be larger:
$ sudo /usr/lib/sendmail -oQ/var/spool/omqueue -qRpost.3.dk -v -O Timeout.queuereturn=10d
(-qRpost3.dk means process only mail for recipient domain post.3.dk) Otherwise, if the remote host is still not available, the mail will be removed from the queue without being send! (that is: you are losing the mail).
If the queue is huge, sendmail needs to go through it completely, before processing anything. That will give messages like these in syslog:
Aug 12 07:44:04 xxxxx sendmail[15662]: [ID 702911 mail.info] grew WorkList for /var/spool/clientmqueue to 46000 Aug 12 07:44:05 xxxxx sendmail[2172]: [ID 702911 mail.info] grew WorkList for /var/spool/clientmqueue to 47000until it has reached the number of mails in the queue. Then flushing will start.
Logging:
Many SMTP implementations do not fully implement the protocol. For example, some personal computer based SMTPs do not understand continuation lines in reply codes. These can be very hard to trace. If you suspect such a problem, you can set traffic logging using the -X flag. For example, '/usr/lib/sendmail -X /tmp/traffic -bd' will log all traffic in the file /tmp/traffic.
This logs a lot of data very quickly and should NEVER be used during normal operations. After starting up such a daemon, force the errant implementation to send a message to your host. All message traffic in and out of sendmail, including the incoming SMTP traffic, will be logged in this file.
/etc/mail/sendmail.mc for MMS M4 gateway on Sun Solaris 8, sendmail 8.11.7p1+Sun.:
divert(-1) dnl This is the macro config file used to generate the /etc/mail/sendmail.cf dnl file. If you modify the file you will have to regenerate the dnl /etc/sendmail.cf by running this macro config through the m4 dnl preprocessor: dnl dnl dnl cd /usr/lib/mail/m4; /usr/ccs/bin/m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf; cd /etc/mail dnl dnl You will need to have the sendmail-cf package installed for this to dnl work. include(`/usr/lib/mail/m4/cf.m4') define(`confDEF_USER_ID',``1:1'') OSTYPE(`solaris8') undefine(`UUCP_RELAY') undefine(`BITNET_RELAY') define(`STATUS_FILE', `/var/adm/sendmail.st')dnl define(`confMAX_MESSAGE_SIZE', `20000000') define(`confTO_CONNECT', `1m') define(`confTRY_NULL_MX_LIST',false) define(`confDONT_PROBE_INTERFACES',true) define(`confTO_IDENT', `15s')dnl define(`confPRIVACY_FLAGS',`goaway') define(`confSMTP_LOGIN_MSG', `')dnl define(`confCW_FILE', `/etc/mail/local-host-names') FEATURE(`use_cw_file') FEATURE(`mailertable',`hash /etc/mail/mailertable')dnl FEATURE(redirect) FEATURE(`access_db',`hash /etc/mail/access') FEATURE(`blacklist_recipients') FEATURE(`delay_checks', `friend') FEATURE(`virtusertable', `hash /etc/mail/virtusertable')dnl FEATURE(`accept_unresolvable_domains') MAILER(smtp) MAILER(local) LOCAL_CONFIG Kmms regex -a@MATCH -m ^\+[0-9]+\/TYPE\=PLMN$ LOCAL_RULESETS Sfinal R$+ @ $j $: $(mms $1 $) @ $j R$+ @MATCH @ $j $: $1
The LOCAL_CONFIG means that the SMTP header recipient address can be non-qualifed as long as it matches that of PLMN-style MMS addresses. The envelope recipient is always full qualified (otherwise sendmail wouldn't know where to route the mail), but some MMSC (at least Nokia's) leaves the header recipient unqualified (fx <+4512345678/TYPE=PLMN>, and sendmail would without the LOCAL_CONFIG append its own fully qualified domain name before passing the mail on to the other operators MM4 gw. Some MMSC become rather unhappy if their recipients have our MM4 gateways FQDN appended...
The mailertable is standard:
mms.mncXXX.mccXXX.gprs smtp:[xxx.xxx.xxx.xx]:[yyy.yyy.yyy.yyy]
The LHS is the envelope recipient domain, the RHS is the IP addresses of the MM4 gateway of the other operator. The mailertable should hold both other operators as well as our own domain and IP addresses of our own MMSC.
The access map is a bit different:
Connect:localhost RELAY Connect:127.0.0.1 RELAY # # Connections from our inside MMSC are allowed Connect:our-mmsc.intra.example.com RELAY # # Our SMTP domain, so the MM4 gw accepts normal email for company users To:example.com RELAY # Our MMS domain, so we accept MMS from other operators To:mms.mnc001.mccXXX.gprs RELAY # One remote operator who is down at the moment. Our inside MMSC is still sending, but we are rejecting. To:mms.mnc002.mccXXX.gprs REJECT # # The same remote operator. We won't take from him for the moment. So his from address is not white listed #From:mms.mnc002.mccXXX.gprs OK # White listing of from addresses from other operators. We only accept from those we have interconnect agreement with From:mms.mnc003.mccXXX.gprs OK From:mms.mnc004.mccXXX.gprs OK From:mms.mnc005.mccXXX.gprs OK From:mms.mnc006.mccXXX.gprs OK From:mms.mnc007.mccXXX.gprs OK # # We accept when local users (root) on our MM4 gw sends email From:mm4gw1.example.com OK From:mm4gw2.example.com OK #
In order to accomplish this white listing functionality from the access map, /usr/lib/mail/m4/proto.m4 is modified to have
$ diff proto.m4 proto.m4.29042004 1585,1586d1584 < # Added by OLMIC 29/04/2004 < R<@> <$+> <$*> $|