For the record, we did some investigation into this (best default
max_size) and I should point out, there are some spammers that
specifically appear to attempt to game the max_size limits, eg including
a larger attachment, to hopefully bypass the scanning size.
I don't think it matters what size you choose, those bad actors will try
to send something bigger. There are other ways to address really big
files, rather than content scanning I would suggest.
However we did try various sizes, to see how the affect on overhead
would be in a typical deployment, and the original size suggestion is
definitely too big.
While we now configure at a larger size than the default, going more
than 1G will cause a serious impact, especially against older mail
servers who might have a more limiting hardware spec.
But yeah, we do see the odd spam message with attachments weighing in at
over 2G as well. For those who want to play, experiment with a two pass
filtering, where the first pass is only about message headers, and
pulling attachment types and names, and the second pass does a deeper
content filtering, and this way you can limit the more resource
intensive second content scan to a smaller size, while the first scan
can be a lot less resource intensive and handle much larger file sizes.
On 2020-02-20 5:17 a.m., [email protected] wrote:
https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7797
--- Comment #8 from AXB <[email protected]> ---
(In reply to AXB from comment #7)
I officially vote -1 for leaving as is. It's configurable so I see no need
to make a change
arg...double negation - whatever , don't change
--
"Catch the Magic of Linux..."
------------------------------------------------------------------------
Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.
------------------------------------------------------------------------
604-682-0300 Beautiful British Columbia, Canada
This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.
