Filetype Checks: No executables on Greek Emails

Steen, Glenn Glenn.Steen at
Mon Apr 8 09:47:18 IST 2013

fre 2013-04-05 klockan 14:37 +0000 skrev Nikolaos Pavlidis:
Hello all,

Many thanks Glenn for the very detailed explanation! I have made the changes and I am holding my breath to see what happens.. after all.. I cannot test it with the email that is in the quarantine.. it is already buggered! Many thanks for all your help.

Final question:

Is disabling that option going to affect the unofficial signature databases I am using with ClamAV?

Thanks again.

Kind regards,


Sorry Nik (and Steve!)... I think I'm turning slightly senile:-)... Steve is right, that option is to dump the entire message *with headers* in there, which is likely harmless to the file command(s)... What I was thinking of, but remembering kind of wrong, was the
Find UU-Encoded Files =
setting ... If that one is "yes", change it to "no".

-- Glenn

From: mailscanner-bounces at [mailto:mailscanner-bounces at] On Behalf Of Glenn Steen
Sent: 05 April 2013 10:11
To: MailScanner discussion
Subject: Re: Filetype Checks: No executables on Greek Emails

BTW, when stripping down the body, you may need "de-MIME" a bit as well, to get the actual thing that file sees... Can be a bit tricky:-).

IIRC there is a common greek greeting phrase that will start with a character that is guaranteed to be interpreted as a DOS executable... so you might not need go through the trouble of the copy/edit thing, just put that greeting in a (text) file and run file/file -i on that... or just cut'n'paste from your MUA, or similar.

I mentioned russion and greek specifically, but this has been reported for other non-english languages as well (french and some south east asian language, at least... for french the culprit was an É or Ë or similar).



-- Glenn

On 5 April 2013 10:54, Glenn Steen <glenn.steen at<mailto:glenn.steen at>> wrote:

I'm guessing that you have

ClamAV Full Message Scan = yes

set in MailScanner.conf ... This will make MailScanner "unpack" the body of the email as a file in the directory presented to ClamAV for scanning (other AVs don't seem to need this "help"). The goal is to catch malware that isn't "properly" encoded, but rather just dumped in the message body.

For non-english locales, especially greek and russian locales, this can be ... less than fortunate, since the "body file" will be present when the file command is run on the directory, and the file command has some very naive one byte magic detection "strings" that will interprete common greek (or russion KOI-8) characters as being the start of an MS-DOS executable (COM-files et al).

When the message is quarantined, the "whole message file" (including headers) is stored in the quarantine (not the file containing just the body), so a simplistic "file message" command will not show the root cause. You need make a copy of that file and manually remove all the headers (and the blank line separating the headers from the body), then run file (and file -i) command on that to see the gory details:).

Provided one has the file -i column in filetypes.rules.conf (it is an optional fifth column, meaning that you likely don't have it and need add it yourself... The columns are <TAB> -separated!), you can use the file -i commands "findings" in that column, for the line that triggers the blocking.... Having lines with file -i "syntax" will make the file -i take precedence ... I think, at least.

The common practice of changing the "File Command = " setting to the file -i command is perhaps less work, but it is also less secure, since the string matching on the result may be even less reliable than usual. Then again, file type checking is more of an art than a science:-):-).

As I'm sure you've noticed, this isn't a new problem, it has been with MailScanner for quite a few years (if not since the very begining). The methods for fixing the problem has varied over the years (editing the magic file, reporting it to the file command maintainers as a bug, using file -i straight up etc), but the interface Jules has provided is actually the very best imaginable, so do explore that... In a stock filetype.rules.conf file there is even an example for the DOS executables that file -i might find (hopefully a bit more securely than the plain file command... Though the commands are actually one and the same, the -i uses a different magic file, not just different descriptive strings).

Changing the ClamAV setting shown above to "no" will make this problem a lot less common (read: go away completely:-), as well, so that might be another very viable option... If you use more than one AV, you don't lose that much security by doing so.



-- Glenn

Den 22 mar 2013 16:40 skrev "Nikolaos Pavlidis" <Nikolaos.Pavlidis at<mailto:Nikolaos.Pavlidis at>>:

Hello all,

I'm having an issue with Mailscanner which weirdly enough has been already discussed here

The problem is:

Mar 22 15:00:18 smtp1 MailScanner[17935]: Filetype Checks: No executables (r2JAPluH011324 )
Mar 22 15:00:46 smtp1 MailScanner[17935]: Saved entire message to /var/spool/MailScanner/quarantine/20130322/r2JAPluH011324


[root at smtp1 r2JAPluH011324]# pwd
[root at smtp1 r2JAPluH011324]# ll
total 28K
-rw------- 1 root root  22K Mar 22 15:00 dfr2JAPluH011324
-rw------- 1 root root 3.7K Mar 22 15:00 qfr2JAPluH011324
[root at smtp1 r2JAPluH011324]# file -i *
dfr2JAPluH011324: text/plain; charset=us-ascii
qfr2JAPluH011324: text/plain; charset=unknown

But I have also added the lines suggested in the previous thread so my filetype.rules.conf looks like:

allow   text            -                       -
allow   -       text/plain      -                       -
allow   -       text/x-mail     -                       -
allow   -       message/rfc822  -                       -
allow   \bscript        -                       -
allow   archive         -                       -
allow   postscript      -                       -
deny    self-extract    No self-extracting archives     No self-extracting archives allowed
deny    executable      No executables          No programs allowed

I have restarted mailscanner before re-queuing the message but always the same result...

Any ideas/recommendations would be much appreciated,

Kind regards,


MailScanner mailing list
mailscanner at<mailto:mailscanner at>

Before posting, read

Support MailScanner development - buy the book off the website!

-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the MailScanner mailing list