https://bz.apache.org/SpamAssassin/show_bug.cgi?id=7797
--- Comment #5 from Henrik Krohns <[email protected]> --- (In reply to Bill Cole from comment #3) > TL;DR Summary: -1, I'm on the verge of closing this as INVALID or WONTFIX, > but want feedback from other SA contributors. Feedback and vote is already 2-1 in favor of raising the limit. It would be strange to close it. > spam messages over 500KB are both relatively uncommon and hard for SA to > identify even if the limit is raised. Completely disagree. Uncommon maybe yes, but not hard to catch. There's still body text that rules and Bayes process, makes no difference if there is a 1MB png or pdf attached. The attachments can also be analyzed with rules and plugins. > in that they are mostly "phishing" messages carrying malware > attachments which are carefully designed to look like high-value types of > mail such as messages with attached business invoices or legal documents. My corpus disagrees. > Because SA is not designed to be nor intended to be a general malware > filter, it is not good at distinguishing between a megabyte of innocent > binary data and a megabyte of malicious code. SA framework can do anything the user wants. Again, a message contains text which is processed by rules and Bayes. Attachments can also be processed. Classifying something as "spam" or "malware" these days is just plain silly. It's all unwanted mail regardless. Even ClamAV is mostly about "spam" these days if using Sanesecurity sigs. I don't even remember the last time I saw a legimate "virus" or "malware" hit. It all ends up in the same trashcan, why would you need separate ones? > There has also been very > little development of SA rules to catch any of the other types of spam that > comprise a substantial fraction of the sparse realm of big spam. Proof? > there is a risk in SA's > rule system of the "catastrophic backtracking" problem inherent in all > regular expression matching systems. When was the last time this was a problem? SA has limited individual matches to few kB block sizes for ages and with the new body part scan size limits and other enhancements 4.0 has, it's good time to raise the default limit a bit for future proofing and general awareness. -- You are receiving this mail because: You are the assignee for the bug.
