Something I did.

[Denis Beauchemin]

Hi John,

Here we solved the problem defining multiple outgoing queues that get
processed less and less often as time goes by.  We also have a job that
moves mails from one queue to the next after some time:
# du -sh /var/spool/mqueue*
3.1M    /var/spool/mqueue
2.2M    /var/spool/mqueue.in
72k     /var/spool/mqueue2
2.5M    /var/spool/mqueue3
7.7M    /var/spool/mqueue4
# ls -ld /var/spool/mqueue*
drwxr-xr-x    2 root     mail        36864 Feb 13 09:06 /var/spool/mqueue/
drwxr-xr-x    2 root     mail        20480 Feb 13 08:33 /var/spool/mqueue2/
drwxr-xr-x    2 root     mail        16384 Feb 13 09:03 /var/spool/mqueue3/
drwxr-xr-x    2 root     mail        32768 Feb 13 09:03 /var/spool/mqueue4/
drwx------    2 root     root        98304 Feb 13 09:06 /var/spool/mqueue.in/
# crontab -l|egrep "send|mq"
13 * * * *      /usr/local/bin/re-mqueue /var/spool/mqueue /var/spool/mqueue2 2700 > /dev/null 2>&1
33 * * * *      /usr/local/bin/re-mqueue /var/spool/mqueue2 /var/spool/mqueue3 11700 > /dev/null 2>&1
03 * * * *      /usr/local/bin/re-mqueue /var/spool/mqueue3 /var/spool/mqueue4 100000 > /dev/null 2>&1
20 * * * *      /usr/sbin/sendmail -oQ/var/spool/mqueue2 -q > /dev/null 2>&1
40 0-23/4 * * * /usr/sbin/sendmail -oQ/var/spool/mqueue3 -q > /dev/null 2>&1
10 0-23/6 * * * /usr/sbin/sendmail -oQ/var/spool/mqueue4 -q > /dev/null 2>&1

Here is some info on re-mqueue:
# re-mqueue -- requeue messages from queueA to queueB based on age.
#
#   Contributed by Paul Pomes <ppomes at Qualcomm.COM>.
#       http://www.qualcomm.com/~ppomes/
#
# Usage: re-mqueue [-d] queueA queueB seconds
#
#  -d       enable debugging
#  queueA   source directory
#  queueB   destination directory
#  seconds  select files older than this number of seconds
#
# Example: re-mqueue /var/spool/mqueue /var/spool/mqueue2 2700
#
# Moves the qf* and df* files for a message from /var/spool/mqueue to
# /var/spool/mqueue2 if the df* file is over 2700 seconds old.
#
# The qf* file can't be used for age checking as it's partially re-written
# with the results of the last queue run.
#
# Rationale: With a limited number of sendmail processes allowed to run,
# messages that can't be delivered immediately slow down the ones that can.
# This becomes especially important when messages are being queued instead
# of delivered right away, or when the queue becomes excessively deep.
# By putting messages that have already failed one or more delivery attempts
# into another queue, the primary queue can be kept small and fast.
#
# On postoffice.cso.uiuc.edu, the primary sendmail daemon runs the queue
# every thirty minutes.  Messages over 45 minutues old are moved to
# /var/spool/mqueue2 where sendmail runs every hour.  Messages more than
# 3.25 hours old are moved to /var/spool/mqueue3 where sendmail runs every
# four hours.  Messages more than a day old are moved to /var/spool/mqueue4
# where sendmail runs three times a day.  The idea is that a message is
# tried at least twice in the first three queues before being moved to the
# old-age ghetto.

I just checked and the link to the author is no longer working.  I could
send it to the list if people are interested.

Denis
Le mer 12/02/2003 à 14:06, John B. Hanks a écrit :
> This is probably old news to most of you, but I am pretty pleased with how
> well it solved my problem so I thought I'd share it and see if it were
> useful or if someone has a better way.
> 
> I have two MailScanner/SpamAssassin machines which act as gateways for our
> campus. Lately, as our mail load has increased (more people are diverting
> incoming mail through us) I have seen a slow rise in the size of the
> outgoing mail queue. Recently when one of our major mailservers was
> experiencing problems, my queues grew to > 8,000 messages and the boxes
> became heavily loaded with sendmail attempting to deliver from this large
> queue directory, to the point where sendmail stopped accepting mail on one
> of the machines. 
> 
> I wanted to make our setup more robust and meet the following goals:
> 
> 1. I must queue mail for 5 days before rejecting it, I promised the users
> that I would do so.
> 2. I did not want to manage multiple queues for different domains or run
> multiple sendmails on different IP addresses to split the load among
> directories.
> 3. I wanted to keep the queues on the mailscanner machines as small as
> possible but not have to manually move messages to alternate queues.
> 4. I wanted the solution to be as simple as possible.
> 
> I found my solution in the FallbackMXhost option. This option basically
> tells sendmail if all else fails when delivering, use this host. I set up a
> third machine which acts as a pretty standard RedHat/sendmail relay box,
> accepting messages and relaying for or to any campus machine (*.usu.edu).
> 
> Then on each mailscanner machine I added this to sendmail.mc:
> 
> define(`confFALLBACK_MX',`queued.usu.edu')
> 
> Then with sendmail.cf regenerated as per the instructions in the sendmail.mc
> file, I restarted MailScanner and watched with great joy as roughly 5,000
> undeliverable SPAM NDRs flowed off the machines and onto the new box. The
> queued.usu.edu machine can be much more patient with retries since once mail
> is there I'm not in any particular hurry to get it delivered.
> 
> YMMV, but it worked for me.
> 
> jbh
-- 
Denis Beauchemin, analyste
Université de Sherbrooke, S.T.I.
T: 819.821.8000x2252 F: 819.821.8045