https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6515
Summary: spamd timeout_child option overrides time_limit
configuration option with nastier behaviour
Product: Spamassassin
Version: 3.3.1
Platform: All
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: spamc/spamd
AssignedTo: [email protected]
ReportedBy: [email protected]
I've spent quite a while tracking down why when I'm running spamd I never see
anything hitting time_limit. The way the code works, we run spamd the
timeout_child value is used to set the deadline and any time_limit value in the
config file is ignored. The problem with this behaviour (apart from not being
documented) is that if the timeout_child limit is exceeded, the connection to
the client is simply closed and a timeout is logged.
However the time_limit method is a nicer way as it actually returns valid data
to the client requesting the scan and provides a score as well. Additionally if
the connection is terminated like this, the client may think there was an issue
with the sa server or its network connection and retry the scan against another
sa server (if we are running a cluster for example).
That's not to say that the timeout_child value in spamd isn't useful though,
because the normal time_limit behaviour won't kick in if we have a run-away
regex or something like that so it does provide extra protection for the
server.
So, I think there are several possible options for what could be done:
1) We could leave as is and put a note in the docs under ::Conf::time_limit
that any time_limit will be ignored when running under spamd
2) We could change spamd to set the master_deadline passed in to spamassassin
to be say 90% of the value of the timeout_child so that most of the time we'll
simply time out in a nice way rather than terminating the connection to the
server (would also want a docs update as in (1) to note that time_limit is
being ignored)
3) We could change spamassassin (->parse()) to take the lower of the
master_deadline and the time_limit.
To me, option 3 seems the most sensible as it allows the most flexibility and
seems the most logical - option 2 still ignores the time_limit value if running
under spamd and also misleads the user as the timeout is not strictly adhered
to.
Here's what I think Mail::SpamAssassin->parse() method should look like if we
go for option (3)
my $master_deadline;
# Passed in at function call
if (ref $suppl_attrib && exists $suppl_attrib->{master_deadline}) {
$master_deadline = $suppl_attrib->{master_deadline}; # may be undef
}
# found in config file - overrides passed in number if lower.
if ($self->{conf}->{time_limit}) { # defined and nonzero
my $time_limit_deadline = $start_time + $self->{conf}->{time_limit};
if( defined $master_deadline && $master_deadline > $time_limit_deadline ) {
$master_deadline = $time_limit_deadline;
}
}
I've got this code running in my environment and it seems to be working, eg
with a 10 second time limit and 300 second timeout_child setting:
2010-11-22T11:38:36+00:00 XXX spamd[5262]: spamd: result: . 0 -
TIME_LIMIT_EXCEEDED,T_RP_MATCHES_RCVD
scantime=11.1,size=542465,user=nobody,uid=99,required_score=7.0,rhost=XXX,raddr=XXX,rport=56137,mid=<XXX>,autolearn=unavailable,shortcircuit=no
2010-11-22T11:43:01+00:00 XXX spamd[5788]: spamd: result: . 0 -
HTML_FONT_FACE_BAD,HTML_MESSAGE,MIME_QP_LONG_LINE
scantime=8.1,size=194707,user=nobody,uid=99,required_score=7.0,rhost=XXX,raddr=XXX,rport=56692,mid=<XXX>,autolearn=disabled,shortcircuit=no
Mark
--
Configure bugmail:
https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
