there is another catch, too, for HTML messages -- it's trivial with CSS or javascript to "pad" a HTML page with an initial 500KB of innocuous content, then "overwrite" that padding with a later chunk of HTML loaded from later in the source.
--j. On Wed, May 20, 2009 at 13:23, Mark Martinec <mark.martinec...@ijs.si> wrote: > Jason, > >> I wonder: what would be the real downside to "spamc -s 500000" actually >> sending the first 500000 bytes instead of sending nothing for email > >> 500K? I realise there would be at least one missing MIME end-boundary, >> but it would still pass all the headers and some of the content... > > Yes, it is useful. It is implemented in the most recent version of > amavisd-new (which is just like spamd, except that is speaks SMTP > instead of a spamc/spamd protocol). I implemented it because I was > getting more spam over 500kB recently, and it proved to be an > effective approach. > > There is a catch though, addressed in the current 3.3 SpamAssassin code. > Truncating a message breaks DKIM and DomainKeys signatures, so the > signatures must either be verified prior to truncation, or SA rules > that penalize non-signed mail from sources that were supposed to > supply a valid signature must be quenched in case of truncation. > The combination of amavisd-new 2.6.3 + SpamAssassin 3.3 handles the > situation correctly and efficiently. > > Mark > >
