On Wed, Mar 31, 2010 at 11:05:57AM -0400, Adam Katz wrote:
> 
> Wasn't some earlier version of SA capable of scanning just the /first/
> [size] of an email?  Probably harder to implement within MIME, but
> some control to internally truncate remaining pieces (for scanning
> only, like the pseudo-headers) would allow scanning beyond the size limit.

SA 3.3 has special handling for truncated messages and amavisd-new (if it's
your choice of glue) has already done it since 2.6.3. Never encountered a
problem with it. Here are release notes for the record:


- large messages beyond $sa_mail_body_size_limit are now partially passed
  to SpamAssassin and other spam scanners for checking: a copy passed to
  a spam scanner is truncated near or slightly past the indicated limit.
  Large messages are no longer given an almost free passage through spam
  checks.

  Note that message truncation can invalidate a DKIM or DK signature.
  If using (non-default) SpamAssassin rules to assign score points to mail
  with no valid signatures from authors which are expected to always provide
  a valid signature, the message truncation can cause false positives on
  these rules. As a workaround, to a truncated message passed to spam
  scanners, amavisd inserts a header field:
    X-Amavis-MessageSize: mmmmm, TRUNCATED to nnnnn
  which can be captured by SpamAssassin rules, e.g.:
    header __TRUNCATED X-Amavis-MessageSize =~ m{\A[^\n]*TRUNCATED}m
  and used in rules like NOTVALID_EBAY to prevent them from triggering.

  Starting with version 3.3.0 of SpamAssassin, its DKIM plugin understands
  the issue and receives undamaged DKIM signature objects directly from
  amavisd, so the above workaround is not needed. Also, a hit on a __TRUNCATED
  rule is automatically generated (explicit header rule is not necessary),
  just in case it might be useful for some purpose.


For other glue, I recommend taking it up with the author to support
truncating properly. (Hmm, I don't think spamc has been enhanced yet..)

Of course we hope that someday SA will have true support for ignoring
useless attachment data.

Reply via email to