Theo Van Dinter wrote: > On Tue, Apr 11, 2006 at 02:14:26PM -0400, Matt Kettler wrote: >> Well, SA automatically ignores attachments in recent versions. However, >> hash-based plugins like razor, dcc, and pyzor work best when seeing all the >> attachments. > > For completeness, the first sentence isn't exactly true. > SA "automatically ignores attachments" for the standard set of body, > header, and uri rules, but it still has to read in the data, store it in > the message tree internally, and make the entire message text available > for full rules.
Fair enough... > There are also things like the AntiVirus plugin, etc, which may go ahead > and decode attachments and do things with the data. I could easily see > a plugin for ClamAV, or something scanning image files, etc. > > I think that at some point, the default size could go up, but I wouldn't > try it for now. FWIW, it might be worth considering the approach used by MailScanner. MailScanner still scans large messages, but truncates messages over "Max SpamAssassin Size". Presumably it does in a manner that still has the correct mime boundaries, because I don't get any kind of superflous rule hits regarding mime boundaries on large messages. I've currently got this set to 60k, but MailScanner defaults to 30k. Of course, this can't work if you're using any kind of encapsulation options in report_safe, but since MailScanner does all the markup itself, it doesn't hurt it to send Mail::SpamAssassin a truncated version. Converting this to the spamc/spamd model might be kind of difficult due to this, but it's worth considering for spamc -c.
