On Wed, 31 Mar 2010, Mark Martinec wrote:
.... and let it handle arbitrary size messages by avoiding its current paradigm of keeping the entire message in memory.
Is there really a problem with the in-memory size? I would have thought the major concern was the processing time for evaluating 'full' (and rawbody?) rules on a large message....
Anyway, the amavisd glue to SpamAssassin does just that: let SpamAssassin see only the first 400 kB (configurable) of a large message, then edit the original message based on results obtained from SpamAssassin.
Good for amavis-d, but not for those of us relying on SA to do the whole job, and not have our MTA's perform any further message modification....
I would be interested in having some of the developers offer an opinion on this. Where is the real 'cost' in running SA against a large message? Is it just the memory used? Or is it, as I suspect, the use of 'full' rules?
- Charles
