|Summary:||allow scanning of multi-MB spam|
|Product:||Spamassassin||Reporter:||Justin Mason <jm>|
|Component:||Libraries||Assignee:||SpamAssassin Developer Mailing List <dev>|
|Version:||SVN Trunk (Latest Devel Version)|
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.