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,
too.
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.
Mark
