On 10/23/2012 10:15 PM, Kevin A. McGrail wrote:> On 10/23/2012 4:10 PM,
Axb wrote:
>> On 10/23/2012 09:59 PM, Kevin A. McGrail wrote:
>>> On 10/23/2012 3:48 PM, [email protected] wrote:
>>>> A message larger than a certain configured size is truncated
>>>> at the configured size and that is what SpamAssassin sees.
>>>> No other contents processing in this data path, just
>>>> blunt truncation of the raw mail message. Works quite well,
>>>> certainly much better than not scanning large messages at all.
>>> Makes sense to me. Something we should consider for SA to do by
default
>>> with spamc/spamd?
>>
>> why? wasn't spamassassin designed to ignore attachements instead of
>> what MailScanner and Amavisd are doing using the API?
>>
>> Why should SA spend time scanning "binary" content it cannot decode or
>> extract anything useful to apply rules?
>>
>> I consider the "chunk" method the worse way to do it as it may skip
>> txt/html content which could show up after the configured chunk size
>> while spending lots of cycles scanning a two liner with an attached
>> 400kb PDF/workd/etc attachement.
>> or did it get it all wrong?
> It's very synergistic because I wrote a note about this 2 days ago.
>
> With SpamC/SpamD, if the email (encoded) is larger than X size, the
> email is not scanned at all.
make it switchable?
scan_chunck yes
scan_chunk_size 400kb
but as a global method change, no thanks.
> My thoughts were to ignore any binary attachments. I even considered
> writing a glue that would rewrite a temporary copy of the email to
> remove binary attachments and see if THAT met the threshold. But if
> real-world experience with simply chopping works well, who am I to
> complain?
I stopped using MailScanner exactly due to that reason: lots of plugins
and rules go nuts over encoded attachements.
Spamc/Spamd's "skip size" method has made a huge *positive* difference
on FPs, and scan times.
The FNs wouldn't *ever* have been caught by a chunk method due to the
kind of content included "above" threshold.
