On 3 Jul 2019, at 14:04, micah anderson wrote:
Giovanni Bechis <giova...@paclan.it> writes:
[...]
This has been superseded by
https://svn.apache.org/repos/asf/spamassassin/trunk/lib/Mail/SpamAssassin/Plugin/OLEMacro.pm
the plugin is for trunk but it works out of the box in 3.4.3rc3 as
well (some work is needed to let it work on 3.4.2)
Can't these be blocked at the MTA level to be much more CPU friendly?
Ask your MTA developer...
However, generally speaking, it won't make much difference whether you
do a specific deep content check in an MTA or in an external filter, if
you're already doing some content checking in an external filter and in
the MTA. There's no way to know what's in a message without receiving
the message, and the incremental cost of one more pattern match is
trivial unless that pattern is unusually complex. In the case of the
OLEMacro plugin, it looks like the analysis it is doing is likely to be
more efficient than doing equivalent matching via SA rawbody regex rules
(which would theoretically be possible, I think...)
What IS more efficient (because it doesn't need to decode, maybe
decompress, and scan every line of a message) is blocking purely by
filename extension in a milter or a MTA header check. That comes at the
cost of rejecting generally harmless attachments.
