You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@spamassassin.apache.org by Justin Mason <jm...@jmason.org> on 2006/04/12 11:34:31 UTC

Re: xxxl spam

Theo Van Dinter writes:
> 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.
> 
> 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.

Matt Sergeant had a good trick in the qpsmtpd SpamAssassin plugin iirc --
it would download the entire message, but after a certain point (e.g.
250k) it would stop writing the incoming data to memory, and instead flush
the remainder to a temporary file on disk.

That way it could keep only the first 250k of messages, scanning that
part, and once complete, reassemble the whole message as it wrote it back
out.

However there may be issues there -- e.g. consider a multipart/alternative
message containing an innocent-looking 600k text/plain, followed by a 10k
text/html spam payload.  Common MUAs would display the latter,
SpamAssassin would scan the former.  That seems to be a vulnerability
to me, although we already don't scan large messages _anyway_ ;)

Also as Theo said, it fails in the face of any kind of message-body
rewriting by SpamAssassin.

--j.