Bug 5832 - M::SA::AI ignores opt_all in its scan stage (it only applies opt_all in its run stage)
Summary: M::SA::AI ignores opt_all in its scan stage (it only applies opt_all in its r...
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: RuleQA (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: Other other
: P5 normal
Target Milestone: ---
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-02-18 15:10 UTC by Daryl C. W. O'Shea
Modified: 2018-09-04 15:30 UTC (History)
2 users (show)


Attachment Type Modified Status Actions Submitter/CLA Status
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Daryl C. W. O'Shea 2008-02-18 15:10:26 UTC 
It seems that the mass-check --server is implying --all causing it to send large
(say 1MB) messages to the mass-check --client which won't scan them unless you
specify --all on the client.
Comment 1 Daryl C. W. O'Shea 2008-02-18 16:06:44 UTC 
This may be a side effect of --cache.  Will look into it later.
Comment 2 Daryl C. W. O'Shea 2008-02-18 21:51:59 UTC 
It turns out that M::SA::AI doesn't limit the message size in the scan stage,
but rather the run stage.  So the mass-check --server will include any message
in its targets, regardless of size, and will send the message to its clients who
may or may not scan large messages depending on if they were run with the --all
option or not.

If none of the clients have the --all option and the mass-check --server has a
large message in its targets it'll keep retrying the large message without
success.  Prior to r628992 that I just committed to implement a limit to the
number of retries (--cs_max_retries=N, default 3) the server would retry these
large messages unsuccessfully forever.

r628992 solves the immediate problem of the mass-check --server never finishing,
but I think the message size limit in M::SA::AI should be moved to the scan
stage.  This would also require modifying the scan cache file format to include
the message size.
Comment 3 Justin Mason 2008-06-01 03:37:16 UTC 
moving to 3.2.6 so that we can release a 3.2.5
Comment 4 Justin Mason 2009-03-29 13:21:18 UTC 
just moving this off the maintainance target
Comment 5 Justin Mason 2010-01-27 02:20:35 UTC 
moving most remaining 3.3.0 bugs to 3.3.1 milestone
Comment 6 Justin Mason 2010-01-27 03:16:20 UTC 
reassigning, too
Comment 7 Justin Mason 2010-03-23 16:33:28 UTC 
moving all open 3.3.1 bugs to 3.3.2
Comment 8 Karsten Bräckelmann 2010-03-23 17:42:39 UTC 
Moving back off of Security, which got changed by accident during the mass Target Milestone move.
Comment 9 Kevin A. McGrail 2013-06-21 16:07:55 UTC 
Moving all open bugs where target is defined and 3.4.0 or lower to 3.4.1 target
Comment 10 Kevin A. McGrail 2015-04-12 15:33:32 UTC 
Pushing to 3.4.2
Comment 11 Kevin A. McGrail 2018-09-04 15:30:19 UTC 
Moving off a specific release as I think this is related to ruleqa/masscheck.  Dave, your thoughts?