On 26/07/2020 11:20, Damian wrote:
in the $banned_filename_re parameter rather than allow zip files. I've tried
searching and have not been able to work out the
different options for the "=>0" bit of the parameter.
Unless you use D_BOUNCE for final banned destiny, only trueness and
defined-falseness of the parameter is relevant.
Does it just mean these files will not be blocked but the rest of the message
will be
checked and these files will still be checked for viruses or does it have wider
reaching consequences?
These files will still be checked for viruses.
Does this approach have any disadvantages?
That depends on your perspective.
A banned rule does not only refer to a specific file but indirectly all files
that are beneath its path. The following is a log
line that shows an executable file, which by itself would be blacklisted but is
effectively permitted because it is inside a
zip-archive using a whitelisted .docx file suffix.
lookup_re(["multipart/mixed","application/octet-stream",".zip","stuff.docx",".exe",".exe-ms","x.com"])
matches key "(?^:\\.docx$)", result="0"
This is because an outer loop loops over banned rules and in each iteration an
inner loop loops over the above list. So if .docx
is whitelisted before .exe is blacklisted, the .exe is still whitelisted in the
above scenario.
Thanks for the response.
What, then, is your recommended solution which generally blocks .zip
files but allows the xlsx, docx and pptx file suffixes?
