Something changed somewhere at some point, unclear if it was on
spamassassin's side or qpsmtpd's, or related to some wierd network
issue, but we've started seeing something (possibly lost FIN packets,
but that makes little sense) causing qpsmtpd to hang waiting for the
spamassasin connection to finish.
hence, a timeout :)
this change will probably aggravate Qpsmtpd::Apache. Improvements
welcome.
I suspect we need a general timeout mechanism for plugin dispatches.
Right now, we only timeout input.
-R
Index: spamassassin
===================================================================
--- spamassassin (revision 849)
+++ spamassassin (working copy)
@@ -65,6 +65,10 @@
=back
+=item timeout [seconds]
+
+How long to wait for spamd? Default 60 seconds.
+
With both of the first options the configuration line will look like the
following
spamasssasin reject_threshold 18 munge_subject_threshold 8
@@ -94,6 +98,7 @@
$self->register_hook("data_post", "check_spam_munge_subject")
if $self->{_args}->{munge_subject_threshold};
+ $self->{timeout} = $self->{_args}->{timeout} || 60;
}
sub hook_data_post { # check_spam
@@ -135,6 +140,14 @@
$self->log(LOGDEBUG, "check_spam: connected to spamd");
SPAMD->autoflush(1);
+
+ local $SIG{ALRM} = sub {
+ $self->qp->respond(451, "An error occured while processing your mail.
(#SA)");
+ $self->log(LOGERROR, "spamassassin timeout");
+ exit(1);
+ };
+
+ alarm $self->{timeout};
$transaction->body_resetpos;
my $username = $self->{_args}->{spamd_user} || getpwuid($>);
@@ -184,6 +197,7 @@
}
my $tests = <SPAMD>;
+ alarm 0;
$tests =~ s/\015//; # hack for outlook
$flag = $flag eq 'True' ? 'Yes' : 'No';
$self->log(LOGDEBUG, "check_spam: finished reading from spamd");
