Bug 5939 - allow scanning of multi-MB spam
Summary: allow scanning of multi-MB spam
Status: RESOLVED DUPLICATE of bug 4469
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: Libraries (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other All
: P5 enhancement
Target Milestone: 3.3.0
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-07-11 01:33 UTC by Justin Mason
Modified: 2009-08-21 08:02 UTC (History)
1 user (show)



Attachment Type Modified Status Actions Submitter/CLA Status

Note You need to log in before you can comment on or make changes to this bug.
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 ***