You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spamassassin.apache.org by bu...@bugzilla.spamassassin.org on 2004/01/28 17:05:21 UTC

[Bug 2977] New: RFE: improve spamc message size limit

http://bugzilla.spamassassin.org/show_bug.cgi?id=2977

           Summary: RFE: improve spamc message size limit
           Product: Spamassassin
           Version: 2.63
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P3
         Component: spamc/spamd
        AssignedTo: spamassassin-dev@incubator.apache.org
        ReportedBy: robert@joseba.easynet.de


Currently spamc does not do any spam checking on large messages.

Consequently we have to configure the message size limit as high as reasonably 
possible to avoid too many false negatives caused by large spam messages.

My suggestion is to introduce a message size limit in the following way.

Assume size of the message to be spam checked is SIZE with 
SIZE=HEADERSIZE+BODYSIZE, the (old, absolute) size limit is LIMIT and the newly 
introduced body size limit is BODYLIMIT.

If SIZE is smaller than LIMIT, then pass the message to spamd.

If HEADERSIZE + BODYLIMIT is larger than LIMIT, then skip the message.

Otherwise:
- split the message into two parts: the initial segment of size 
  HEADERSIZE+BODYLIMIT and the remainder of size BODYSIZE-BODYLIMIT
- pass the initial segment to spamd
- take the result of spamd, append then remainder to it. This reconstructed 
message is the final spam checked email

Using the above algorithm we can set the size limit rather low, say 5kB. Spam 
checking will be pretty much as effective as if the full message was checked, 
while consuming considerably less resources since messages in the range of, say, 
 10kB-250kB are checked faster.

I am currently using a similar strategy on a little Perl program calling SA 
directly and it works well.

The above works with report_safe=0. If report_safe is set, the spamd/spamc 
interaction would need to be modified so that the final MIME boundary marker  
can by added in the right place. It should still be worth while, though.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.