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.
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?
regards,
KAM
