https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6515

--- Comment #9 from Mark Martinec <[email protected]> 2011-05-12 15:56:04 
UTC ---
Sorry for coming late for the show. I haven't noticed the spamd problem
as I mostly run SpamAssassin from amavisd and the time limiting worked
fine there, and my limited testing of spamd didn't reveal the trouble.

I agree with the proposed patch, makes sense to use a minimum of both
values, and if that resolves the spamd problem than that's it. I've attached
the patch which is essentially as per comment 1, with updated docs,
and addressing the need to be able to specify a different score for
synthetic rule hits, as per comment 5.


> The problem with this behaviour (apart from not being documented)

It *was* documented:

$ man Mail::SpamAssassin::Conf
  time_limit n   (default: 300)
[...]
  This deadline may be overruled by a caller through option
  'master_deadline' in $suppl_attrib on a call to parse(), possibly
  providing a more accurate deadline taking into account past and
  expected future processing of a message in a mail filtering setup.
  Note that spamd (and possibly some third-party callers of
  SpamAssassin) will overrule the "time_limit" setting based on its
  --timeout-child option, unlike the command line "spamassassin",
  which has no such command line option.


> The spamd time limit options are command line parameters.
> Is there documentation somewhere that leads you to believe
> you can specify them in a configuration file

Both the time_limit config option, as well as the spamd's
option --timeout-child are documented.


> Second, I would argue that amu response, positive, negative, zero, etc.
> if the child timeout is reached is invalid OTHER than a response that
> says the child timed out.

For a pre-queue content filtering this is unacceptable, it was passing
through way too much spam. If the behaviour is undesirable, either
specify a very large timeout values, or provide a negative score for
the TIME_LIMIT_EXCEEDED rule. This was indeed a bit clumsy (needed
a meta rule), but with the supplied patch just setting a score for
TIME_LIMIT_EXCEEDED to a large negative value will make it behave
as whitelisting, if someone really wants it.

In practice it is very uncommon that a late-running rule would provide
a large negative score thus saving a message that has so far accumulated
a substantial positive score.

-- 
Configure bugmail: 
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to