False positives "text/plain,.exe"
Mark.Martinec+amavis at ijs.si
Tue Apr 26 17:46:09 CEST 2016
Tilman Schmidt wrote:
> On our mailserver, Amavis is quarantining a lot of mails claiming that
> they contain a banned attachment of type "text/plain,.exe" even though,
> when inspecting the quarantined mail, they turn out not to contain any
> attachment at all, not even an image or signature, just "text/plain"
> and possibly "text/html" within "multipart/alternative".
> Most frequent victims of this are mailing list messages from the Python
> mailing list, but other quite innocuous individual mails are affected,
> This is becoming quite annoying for the users and creates unnecessary
> work for the administrators to check and release all those messages.
> Is this a known problem? How can it be fixed?
The "text/plain,.exe" means the declared MIME part was text/plain,
but the file(1) utility decided that it is some kind of executable.
Your sample (decoded and given to a file(1) utility) here reports:
Python script, Non-ISO extended-ASCII text executable
and an entry in the @$map_full_type_to_short_type_re list
matches /\bexecutable\b/i, returning the '.exe':
[qr/\bexecutable\b/i => 'exe'],
Perhaps an entry like the following should be added to the
default @$map_full_type_to_short_type_re list:
[qr/Python script, .*text executable\b/ => 'txt'],
or the existing one relaxed:
< [qr/\bscript text executable\b/ => 'txt'],
> [qr/\bscript\b.*text executable\b/ => 'txt'],
Will do this for the 2.11 release, thanks for the report
and the sample.
More information about the amavis-users