I guess this qualifies as a hijacked thread now (or at least topic
drift). ;)
On 6 Jul 2005 at 11:28, Herb Martin wrote about
"RE: [exim] O¨Reilly Exim book usefu":
Please don't snip relevant attributions when replying.
| (restored) On 6 Jul 2005 at 8:57, Fred Viles wrote about
| "RE: [exim] O¨Reilly Exim book usefu":
|...
| > Supposedly, everything "demime" can do can be done using the
| > more general capabilities of the MIME ACL. But if it ever
| > does disappear, I will sorely miss it as it is a much simpler
| > and more straightforward UI for the things it does.
|
| But that is part of the point if the MIME ACL does NOT allow
| the MALWARE but the MIME ACL is supposed to replace DEMIME
| (in Data ACL) then you have the case that you cannot replace
| it completely.
An unanswered question is whether there are still any AV scanners
that can't unpack MIME messages for themselves, and hence still need
demime. ClamAV does not (still need it), contrary to the
documentation.
| (On can question the need for demime but that is not the same
| as saying that the MIME Acl can replace "demime with malware".
Since malware doesn't go in the MIME ACL, I assume what you mean is
that if the AV scanner doesn't unpack MIME messages, demime is still
needed for malware to work.
Actually, I'm not sure that's true. Assuming the scanner will scan
any and all files in the directory it's passed, I think having
decode = default
in the MIME ACL means the decoded parts will still be in the scan
directory when the scanner is run in the DATA ACL. The docs don't
explicitly mention this, though.
|...
| Spam and Virus Scanning with Exim 4
| using Exiscan and/or SA-Exim Mini-HOWTO
| http://www.timj.co.uk/linux/Exim-SpamAndVirusScanning.pdf
| 6.2.5.2. In the MIME ACL
|
| deny message = ...contains ... harmful content ($malware_name)
| malware = *
Tim!
- Fred
