Bug 3206 - spamd flags: -q and -Q prevents spamd processing
Summary: spamd flags: -q and -Q prevents spamd processing
Status: NEW
Alias: None
Product: Spamassassin
Classification: Unclassified
Component: spamc/spamd (show other bugs)
Version: SVN Trunk (Latest Devel Version)
Hardware: All Linux
: P5 enhancement
Target Milestone: Future
Assignee: SpamAssassin Developer Mailing List
Depends on:
Reported: 2004-03-22 15:13 UTC by Dallas Engelken
Modified: 2019-09-25 03:45 UTC (History)
2 users (show)

Attachment Type Modified Status Actions Submitter/CLA Status
patch against spamd.raw patch None Dallas Engelken [HasCLA]

Note You need to log in before you can comment on or make changes to this bug.
Description Dallas Engelken 2004-03-22 15:13:53 UTC
if i start a spamd server on port 785 without the -q/-Q flag, it works... if i 
start a spamd server on 786 with the -q/-Q flag, it doesnt work.  

this is:
[root@spamd1 spamd]# spamassassin -V
SpamAssassin version 3.0.0-r9592

[root@spamd1 spamd]# /usr/bin/spamd -A, -i -p 
785 -m15 -x -d

[root@spamd1 spamd]# echo | spamc -p785
X-Spam-Score: 3.9
X-Spam-Flag: NO
X-Spam-Bayes-Auto-Learn: no
X-Spam-Level: ***
X-Spam-Status: No, hits=3.9 required=4.0
X-Spam-Checker-Version: SpamAssassin 3.0.0-r9592 on spamd1.ruraltel.net
X-Spam-Required-Score: 4.0
X-Spam-Report: 3.9 points, 4.0 required
        *  1.9 DATE_MISSING Missing Date: header
        *  2.0 FROM_NO_LOWER 'From' has no lower-case characters
        *  0.0 MISSING_HEADERS Missing To: header
X-Spam-Bayes-Probability: 0.5

[root@spamd1 spamd]# /usr/bin/spamd -A, -i -p 
786 -Q -m15 -x -d

[root@spamd1 spamd]# echo | spamc -p786

[root@spamd1 spamd]#
Comment 1 Dallas Engelken 2004-04-12 07:55:51 UTC
tested on Fedora Core 1 and have no problems running -Q/-q.  RedHat 7.3 however 
experiences the same issue.  Can perl 5.6.1 be the cause of this??
Comment 2 Dallas Engelken 2004-04-12 08:46:01 UTC
Created attachment 1886 [details]
patch against spamd.raw

patch against spamd to remove exits from sql-config failure
Comment 3 Dallas Engelken 2004-04-12 08:46:36 UTC
okay.. so i've figured out what is wrong.

an invalid custom query (but not really because it worked from sql command 
line) string in user_scores_sql_custom_query will cause 
spamd to exit.  The query in question had a % sign in it by the _DOMAIN_ 
part ...  it would  process  echo | spamc -u 'dallase@nmgi.com'   but would not 
process echo | spamc or echo | spamc -u 'root'  because the domain part would 
be NULL.  weird...

my patch against spamd.raw removes the exits completely so the sql_config calls 
look more like the other calls to similar user config stores (ldap and virtual 

The only benefit I see in having that exit in there woud be this situation:

if SQL prefs cannot be pulled, and someone wants to prevent accepting mail if 
it cannot pull sql prefs, they could use spamc -x and catch the exit code 74 
and tempfail on it.   Maybe it needs to be a configurable option...  I myself 
would rather have mail be processed than tempfailed because I couldnt pull 
someones user_prefs.


Comment 4 Michael Parker 2004-04-12 09:00:37 UTC
Subject: Re:  spamd flags:  -q and -Q prevents spamd processing

Seems like you're throwing the baby out with the bath water.

See Bug 1222 for info on returning a service unavailable error when
the query fails.

Possibly there is a problem with the custom SQL stuff that we should
fix, but I'd need more information.

I'd entertain some discussion on an additional param that specified
failures should just continue processing, but I tend to believe that
is a bad idea.


Comment 5 Dallas Engelken 2004-04-12 09:23:28 UTC
how about if -f is specified, it doesnt exit, and if -x is specified, it does 
exit??   those spamc parameters basically tell you if someone is wanting to 
capture the exit codes to tempfail or not.

If i run with spamc -f, i dont want SQL errors causing my scans to stop.  If I 
run with spamc -x, I want SQL errors to cause mail to tempfail.

seem reasonable?
Comment 6 Daniel Quinlan 2005-03-30 01:09:12 UTC
move bug to Future milestone (previously set to Future -- I hope)
Comment 7 Bill Cole 2019-09-25 03:45:14 UTC
This morphed from bug to RFE for flexible handling of bad config. Fixing classification.