Bug 4903 - spamc shouldn't use the -t parameter as connection timeout
Summary: spamc shouldn't use the -t parameter as connection timeout
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: 3.1.1
Hardware: Other All
: P5 normal
Target Milestone: Undefined
Assignee: SpamAssassin Developer Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-05-17 18:21 UTC by David Schweikert
Modified: 2006-05-17 11:21 UTC (History)
0 users


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 David Schweikert 2006-05-17 18:21:50 UTC 
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...