https://issues.apache.org/SpamAssassin/show_bug.cgi?id=5939
Summary: allow scanning of multi-MB spam
Product: Spamassassin
Version: SVN Trunk (Latest Devel Version)
Platform: Other
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P5
Component: Libraries
AssignedTo: dev@???
ReportedBy: jm@???
as per Chris' thread on the users list:
Chris said:
On Thursday 10 July 2008 9:05 pm, Theo Van Dinter wrote:
> On Thu, Jul 10, 2008 at 07:45:30PM -0500, Chris wrote:
> > :0 fw : $ASSASSINLOCK
> >
> > * < 3000000
> >
> > | /usr/bin/spamc -f
> >
> > will it be worth it to adjust upwards? This not a mail server but just a
> > home system with one user, me.
>
> The size limitation is useless, spamc has a smaller default limit.
>
> I wouldn't worry about a 7m spam, unless all (or at least a significant
> portion of) spams become that size.
Only 9 of 182 for this month are above 400k. So nothing to be concerned about
yet, thanks Theo.
that's 5% of his spam getting past SA due to our size limits. now that's
just one user, I haven't seen any of this, but I think this is likely
to increase as time goes on; I've heard that huge spam is widespread in
.jp, where they have very high bandwidth end-user broadband deals.
IMO we should try to come up with a way to deal with massive messages --
even if that's just a matter of streaming the overflow to disk, and ignoring
it for purposes of scanning. Sure, this could allow a spammer sending HTML
to disguise the "bad content" by prepending 400KB of innocent content
and using CSS tricks to shift the "bad stuff" up top at render-time -- but
this is better than the current situation, where we simply give a message of
that size a "free pass" outright.
--
Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
