Bug 5939

Summary: allow scanning of multi-MB spam
Product: Spamassassin Reporter: Justin Mason <jm>
Component: LibrariesAssignee: SpamAssassin Developer Mailing List <dev>
Severity: enhancement CC: James.Wilkinson
Priority: P5    
Version: SVN Trunk (Latest Devel Version)   
Target Milestone: 3.3.0   
Hardware: Other   
OS: All   

Description Justin Mason 2008-07-11 01:33:40 UTC
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.
Comment 1 Mark Martinec 2009-08-21 08:02:54 UTC
Closely related to:

Bug 4469
  Add a process/option to efficiently deal
  with very long mail messages

*** This bug has been marked as a duplicate of bug 4469 ***