Orphan files in /var/spool/mqueue.in

[Plant, Dean]

Glenn Steen wrote:
> On 24/11/06, Randal, Phil <prandal at herefordshire.gov.uk> wrote:
>> That is an ancient version of MailScanner.  You should upgrade it to
>> the latest version and then see what happens.
>> 
>> Phil
>> 
>> --
>> Phil Randal
>> Network Engineer
>> Herefordshire Council
>> Hereford, UK
>> 
>>> -----Original Message-----
>>> From: mailscanner-bounces at lists.mailscanner.info
>>> [mailto:mailscanner-bounces at lists.mailscanner.info] On Behalf
>>> Of Plant, Dean
>>> Sent: 24 November 2006 14:56
>>> To: MailScanner discussion
>>> Subject: Orphan files in /var/spool/mqueue.in
>>> 
>>> I am curious if the orphan files that I have to clear out of
>>> /var/spool/mqueue.in every so often is something that other people
>>> experience or do I have a problem that should be investigated
>>> further. These files build up at the rate of about 3-4 a day on each
>>> server which
>>> deal with about 30,000 messages a day, I have the lock type
>>> set to posix
>>> and I am using the standard sendmail 8.13 rpm's from CentOS 4 with
>>> MailScanner v4.52.2 
>>> 
>>> Thanks
>>> 
>>> Dean
>>> 
> Another thought is that that few a message "corrupted" might actually
> be quite normal with that amount of messages.
> AFAICR, there are a couple of situations where those might occur...
> Please correct me if I'm wrong... Client dropping connection during
> DATA could be it (should have a matching entry in the logs then), or
> forcibly interrupting sendmail while it is transferring data from the
> client come to mind. Both should be visible in the logs.
> 
> Me not being a rendmaul admin (any more:-), I might be completely
> wrong;-) Cheers


Thanks for everyone's replies and suggestions.

The mail log does indeed show what is happening (Slap on the wrist for
not checking this first).

All the orphan files are from lost connections which, as suggested in
another reply, is probably fixed in a later sendmail release. It does
give me piece of mind now I know why these are left in mqueue.in and am
a lot happier removing them via a cron job. Also we are using sendmail's
greet_pause feature and milter-ahead.

And yes our MailScanner version is ancient but similar to John Rudd we
tend to upgrade only if we know it is going to fix our problem. In fact
apart from this issue our mail servers run without problem. I did also
check the change log to see if any fixes were listed for orphan files.

Mail log entries for orphan messages left in /var/spool/mqueue.in

Nov 24 09:49:17 rsys002x milter-ahead[12570]: 32953 kAO9nAif023022:
recipient <********@******> (0) cached, skipping
Nov 24 10:59:51 rsys002x sendmail[23022]: kAO9nAif023022: SYSERR(root):
collect: read timeout on connection from [89.108.144.156],
from=<wutzz at dubuisson-sa.com>
Nov 24 10:59:51 rsys002x sendmail[23022]: kAO9nAif023022:
from=<wutzz at dubuisson-sa.com>, size=7883, class=0, nrcpts=1, proto=SMTP,
daemon=MTA, relay=[89.108.144.156]

Nov 21 21:25:15 rsys002x milter-ahead[12570]: 29208 kALLOsBe013833:
recipient <********@******> (0) cached, skipping
Nov 21 22:33:39 rsys002x sendmail[13833]: kALLOsBe013833: SYSERR(root):
collect: read timeout on connection from [80.50.62.218],
from=<atwater at dtisoft.com>
Nov 21 22:33:39 rsys002x sendmail[13833]: kALLOsBe013833:
from=<atwater at dtisoft.com>, size=5727, class=0, nrcpts=1, proto=SMTP,
daemon=MTA, relay=[80.50.62.218]

Nov 21 13:58:06 rsys002x milter-ahead[12570]: 20431 kALDvvG0018349:
recipient <********@******> (0) cached, skipping
Nov 21 14:58:11 rsys002x sendmail[18349]: kALDvvG0018349: SYSERR(root):
collect: read timeout on connection from
59.161.71.187.del-cdma.dialup.vsnl.net.in, from=<********@******>
Nov 21 14:58:11 rsys002x sendmail[18349]: kALDvvG0018349:
from=<********@******>, size=5579, class=0, nrcpts=1, proto=ESMTP,
daemon=MTA, relay=59.161.71.187.del-cdma.dialup.vsnl.net.in
[59.161.71.187] (may be forged)

Thanks again.

Dean.