Betr.: RE: docx trash files

Arjan Melein Amelein at
Thu Sep 10 14:22:49 UTC 2015

I'm guessing with docx it's triggering on the 'Archives: Filetype Rules'
setting (or any of the 'Archives:' ones)
I'm assuming it still won't work if I add a regexp to the allow
filenames, I really can't risk accidentally allowing any (archived)
executable these days with all the cryptocrap.
It would be nice if we can somehow get a bit more fine control with
allow/deny exceptions.

>>> PSI Mailbag <mailbag at> 4-9-2015 14:27 >>>
> Did you add the docx extension to your filename.rules? If you did and
it is still being blocked, it is probably an Office
> 2007 docx which looks like an executable MIME type to the Linux
*file* command. 

Adding it to the filename.rules will have no impact, as the conflict is
on the filetype.rules which are triggering on the 0000.dat within the
docx (as the docx format is really just a glorified zip file). Without
allowing all executables, you could edit and recompile your "magic" file
(/usr/share/misc/magic on RHEL 6), which controls how the "file" command
interprets what type of file you're looking at. If I'm not mistaken,
it's one of the first definitions after the comment with ".COM formats
(Daniel Quinlan, quinlan at". You'll find it defined twice
in the file as well. If you do decide to edit the file, you'll have to
compile it to the magic.mgc (in the same directly), which is what
actually controls the logic. You should probably make the files
immutable as well, or a future update will wipe out your edits. Note
that this does remove some filetype detections for other generic COM
files as well.


MailScanner mailing list
mailscanner at 

More information about the MailScanner mailing list