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 2006/05/17 20:21:50 UTC
[Bug 4903] New: spamc shouldn't use the -t parameter as connection timeout
http://issues.apache.org/SpamAssassin/show_bug.cgi?id=4903
Summary: spamc shouldn't use the -t parameter as connection
timeout
Product: Spamassassin
Version: 3.1.1
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P5
Component: spamc/spamd
AssignedTo: dev@spamassassin.apache.org
ReportedBy: dws@ee.ethz.ch
When a host is down, spamc does try three times to contact one of the hosts
given with -d and fails after the third failure. Everytime, the value given with
-t is used before the next host is tried. If, for example, -t 300 is used and
the spamd server(s) is down, it is going to take 15 minutes until spamc exits,
which is 3 times the timeout that I am expecting.
If you combine this for example with Postfix's killing of the delivery process
after another timeout value (which you might intuitively choose a little bit
higher than what is set for spamc), then the system starts to send bounces back.
I think that using the '-t'-specified value as connect-timeout is not necessary
and doesn't do what the user expects. Setting the connect-timeout to a fixed
value like 5 or 10 seconds should be ok in any case. If necessary, a separate
parameter for the connect-timeout could be used...
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.