[Mimedefang] Parser: can't flush: No space left on device and big files in /tmp

[Bill Cole]

On 28 Oct 2015, at 16:48, Tom Knutson wrote:

> Lately we are seeing this error in the maillog several times a day:
>
> Oct 28 15:10:03 mail mimedefang-multiplexor[37348]: Slave 1 stderr:
> MIME::Parser: can't flush: No space left on device at
> /usr/local/lib/perl5/site_perl/5.8.9/MIME/Parser.pm line 815, <FILE>
> line 2700428.
>
> The /var drive has plenty of room. The /tmp drive is nearly full with
> 5 large files owned by mailnull:
>
> -rw-------  1 mailnull  wheel     167779519 Oct 28 12:39 qhNzfFSRG3
>
> If I delete one of these large files in /tmp, they reappear after a 
> few minutes.

Any Perl module using File::Temp with default parameters (which can 
include MIME::Parser, via MIME::Tools) will create temp files with 
10-character random-alphanumeric names in /tmp  and if the calling 
process is running as mailnull (the default for anything hooked into 
sendmail on FreeBSD) they will be owned by mailnull.


> This started about a week ago on a system that has been running OK for
> quite a while.
>
> FreeBSD 7.1
> Mimedefang 2.64_1
> clamav 0.97.6
> spamassassin 3.3.2
> perl 5.8.9

So you're a fan of 2008? :)

I sincerely hope that machine is well-guarded externally, hardened 
internally, poorly publicized, and carefully watched. Note that beyond 
the obvious issue of security, those versions of clamav and spamassassin 
are substantially disabled by their age.

> I have tried restarting mimedefang.
>
> Are these big files being created by mimedefang?

Probably so, indirectly. MIME::Parser can create files like that and 
will die as you've seen if /tmp fills while it needs to write one. And 
to quote from mimedefang.pl itself:

    use MIME::Parser;


> I didn't think it
> used /tmp by default.

Not directly and implicitly, but indeed it does and so will a lot of 
other common Unix gadgets (e.g. mailx, cron, etc.) so if you have a 
chronic issue of /tmp filling you will have a chronically and diversely 
dysfunctional system.

> Could this problem be caused by cleverly crafted
> spam?

Possibly. Also possible: very large messages or messages that innocently 
catch on one of ~3 dozen bugs fixed in the MIME-Tools suite since the 
last version you are likely to have installed, in such a fashion that it 
goes insane and fills its temp files to the point of filling /tmp.

> Suggestions on how to troubleshoot this would be appreciated.

I'm torn ethically on offering deep "troubleshooting" suggestions 
because I don't think it is in your interest to try to keep that system 
running in its antiquated and intrinsically non-securable state. But 
here are some vague suggestions, with the caveat that I hope you start 
with the last one...

It may be that all you need to do is to configure your MTA to advertise 
a sane maximum mail size limit so people stop trying to mail you CD 
images. Using mail to transport objects >160MB is not sane. But then, 
neither is handling modern Internet mail on a system that hasn't been 
updated in 7 years...

Of course, you could also try slapping an extra GB into /tmp to give 
MIME::Parser room to blow up even worse OR handle the giant messages. 
You could also fiddle with how MD is being launched to put 
TMPDIR=/var/tmp into its environment, which should make these beasts go 
there (and maybe fill /var for you, breaking so much more)

If you're actually receiving messages that are >160MB intentionally, you 
can make them bypass MD content scanning in mimedefang-filter, but I'm 
not actually sure if that works for the basic MIME parsing step.

Adding logging code in mimedefang-filter can help nail down which 
messages are the cause of the giant files filling /tmp.

Ultimately, you should update to a maintainable OS version (i.e. FreeBSD 
9.3 at least) and current versions of all of the other software 
involved.