[conspire] Some spam handling

[Rick Moen]

Just a brief follow-up:

> [...] spamd lacks the ability (in the version I have installed, at
> least) to, say, read and analyse the first 256kB of any large message
> and ignore everything after that.

(Which would be what the quotation below calls 'truncating'.)

The Spamassassin maintainers explained the logic of the code's behaviour
on their dev mailing list
(http://www.gossamer-threads.com/lists/spamassassin/users/113696):

   OK, truncation might be a better policy, as long as the threshold is 
   nearer what we use now -- 500KB rather than 64KB. ;) 

   By the way, an explanation of the current policy: 

   We can say with that only messages below a high-enough threshold should
   be scanned, and have a good degree of certainty that this will allow us to 
   avoid crazy memory consumption/slow scan times/etc., while allowing 
   through only 0.001% of spam. 

   This works, because spammers need to be able to send out a certain
   number of spam messages per day as part of their economic model, and 
   this is partly bottlenecked by the size of each message; increasing 
   the average size of their spams from 7KB (my current avg spam size) 
   to 600KB to evade SpamAssassin's limits, for example, means that 
   their spam output would drop to 1.1% of what it was previously. 

   (Mind you, certain subsets of spammers, such as the japanese-language
   porn spammers, seem to send larger messages, probably since they're 
   not as concerned with volumes.) 

The SpamAssassin version I'm currently running default-omits scanning of
any message over 256kB long.  Starting with version 3.2, that was upped
to 500kB.

I haven't bothered to look inside the attached Zip files of the recent
mails that I _think_ are the ones Daniel commented on, but figured they
were extremely likely to be yet more MS-Windows malware.