Removing old files from mqueue

Each message in the mail queue is composed of a df... and qf... file. To remove messages on a specific date or range of dates you'd get a listing (ls -l /var/mqueue) and delete the qf & df files for those dates.  If there's a lot in mqueue you can place the result of the file list into a file (ls -l /var/spool/mqueue >/tmp/mqueue.list), edit that and retain only the file names the need to be deleted, and use xargs to delete those files. Another way, which is what I sometimes do, is to use dired mode in Xemacs/Emacs.

It's a basic question I suppose but there it goes: How do I use xargs to delete the files?

how long should I keep those kind of files?

In general, the default for a mail system is to retry messages for 4-5 days. If they can't be delivered in that time they'll be automatically deleted. Since one typically run the queue fairly freqeuntly these retries can consume a lot of resources on a busy mail server. I set up my Sendmail servers with aged delivery queues. The default queue is run at 15 minute intervals and once delivery of a message has been attempted at least twice it gets moved to a queue that's only run every only run every 4 hours. Messages in that queue are tried at least twice and then moved to a queue that's only run once a day.

where and how do I control the automatically time for messages deletion ?

This is controlled by the confTO_QUEUERETURN variables set when sendmail.cf is built. From the cf/README:

confTO_QUEUERETURN      Timeout.queuereturn
                              [5d] The timeout before a message is
                              returned as undeliverable.
confTO_QUEUERETURN_NORMAL
                  Timeout.queuereturn.normal
                              [undefined] As above, for normal
                              priority messages.
confTO_QUEUERETURN_URGENT
                  Timeout.queuereturn.urgent
                              [undefined] As above, for urgent
                              priority messages.
confTO_QUEUERETURN_NONURGENT
                  Timeout.queuereturn.non-urgent
                              [undefined] As above, for non-urgent
                              (low) priority messages.

can't find that lines. sendmail is running in a VPS.

sendmail (8.11.x)  cf has the following lines:

#############
#  Options  #
#############

Oa1                  # Wait (in minutes) for alias file rebuild
OA/etc/aliases            # location of alias file
OC10                  # Checkpoint queue runs every N deliveries
OF0600                  # Temporary file mode
Og100                  # Default GID
OH/etc/sendmail.hf                    # SMTP help file
OI                  # Insist that the name server be running
Ok5                  # Open connection cache size
Om                  # Expand aliases to include sender
On                  # Verify RHS in newaliases
OQ/var/spool/mqueue                      # Queue directory
OS/etc/sendmail.st            # Stat file
OT3d                  # Queue timeout and warning time
Ou126                  # Default UID
Ot                  # Use TZ environment variable
Opauthwarnings,noexpn,novrfy

OT3d  looks to be setting. Be careful and don't set the timeout too low. Personally I would not set it below 4 days since this is the generally accepted amount of time that a server could be unavailable and mail would not be lost.

besides this setting (3d) the queue keeps files from 20 days or more. why?

Unless something is seriously wrong with your systems there should not be any complete messages in mqueue older than 3 days. Remember that a complete message is composed of qf & df files with the same ID. It is possible, and even probable, that you'll wind up with files in mqueue that were created during a mail transaction that aborted. In that case you won't find a qf/df pair with the same id and 'mailq' won't list those ID's.

Running mailq I get these results:

. . .
i4511L3Z002651   226481 Tue May  4 22:02 <informativo@castelotrailer.com.br>
                 (User unknown)
                                         <nubia.sc@ibest.com.br>
                                         <ney.guedes@ibest.com.br>
                                         <netobianchi@ibest.com.br>
i44MbEbb018455   226481 Tue May  4 19:40 <informativo@castelotrailer.com.br>
                 (I/O error)
                                         <alexandrecois@hotmail.com>
                                         <artur_sam@hotmail.com>
                                         <alerrandrofarias@hotmail.com>
                                         <ale_gda@hotmail.com>
                                         <albertoluiz2001@hotmail.com>
                                         <euclides88@hotmail.com>
                                         <ahilzendeger@hotmail.com>
                                         <agriders@hotmail.com>
                                         <afrancosta@hotmail.com>
                                         <afpolido@hotmail.com>
                                         <ailton@novavisaonet.com.br>
i451i8E1035958   226481 Tue May  4 22:45 <informativo@castelotrailer.com.br>
                 (Service unavailable)
                                         <xavier_on_line@bol.com.br>
                                         <xande-vieira@bol.com.br>
                                         <wulk@bol.com.br>
. . .
                Total requests: 153

There is a total of 1110 files in mqueue.

That means that you have 153 real messages, in files like:

dfi4511L3Z002651
dfi44MbEbb018455
dfi451i8E1035958
...
qfi4511L3Z002651
qfi44MbEbb018455
qfi451i8E1035958

and a bunch (804) of old partial message files in /var/spool/mqueue. A quick fix would be to execute 'find /var/spool/mqueue -ctime +5 -exec rm {} \;' which will delete anything 5 or more days old.

how can I give you more points?

what "partial messages" does it mean?

>  how can I give you more points?

That's not necessary.

>  what "partial messages" does it mean?

Partial messages can result when a remote agent has opened an SMTP session and started to deliver a message to Sendmail. If that connection unexpectedly closes or either end aborts in "mid message" it is possible to wind up with a partially complete transaction in mqueue.