[opensuse] Spamassassin blacklist_from not working ??
I have some "blacklist_from" entries in my .spamassassin/user_prefs blacklist_from *@sendio.pl blacklist_from *@supermailito.pl They don't seem to be working; mail from those sites is getting though unaltered. I'm using 'spamd', started by systemd. I've just restarted that to make sure: # ps -ef | grep spam root 6017 1 0 08:08 ? 00:00:01 /usr/sbin/spamd -d -c -L -r /var/run/spamd.pid root 6018 6017 0 08:08 ? 00:00:00 spamd child root 6019 6017 0 08:08 ? 00:00:00 spamd child My .fetchmailrc piped to procmail: mda "/usr/bin/procmail -f %F -d %T"; and procmail pipes to spamassassin :0 fw: /tmp/spamassassin.lock * < 256000 | /usr/bin/spamc I realise there are other ways of doing this involving .forward and Postfix with a modified mail.cf but this way I'm doing strikes me as minimalist and least dependencies. I can't see why it shouldn't work. However those addresses are getting though! I can't see why. I can add debug to my .procmail but that doesn't let me see the working *within* spamassassin. All I can see it how it rates SPAM, not what it does with blacklist items. Any idea how I can drill down with the debug? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-07-22 14:38, Anton Aylward wrote:
I have some "blacklist_from" entries in my .spamassassin/user_prefs
blacklist_from *@sendio.pl blacklist_from *@supermailito.pl
The syntax is correct. I have entries in the same style.
and procmail pipes to spamassassin
:0 fw: /tmp/spamassassin.lock * < 256000 | /usr/bin/spamc
Here I do it differently: :0fw | /usr/bin/spamc -s 25000000 :0 aw: $HOME/Mail/.D-locks/zap_spam_coitt.lock * ^X-Spam-Status: Yes | $DELIVER -m zap_spam_coitt or :0fw | /usr/bin/spamc -s 25000000 :0 a * ^X-Spam-Status: Yes $HOME/Mail/zap_spam_ggle Your " * < 256000" line strikes me as weird.
I can't see why it shouldn't work. However those addresses are getting though! I can't see why.
I can add debug to my .procmail but that doesn't let me see the working *within* spamassassin. All I can see it how it rates SPAM, not what it does with blacklist items.
Are you sure that mail is being passed to spamc?
Any idea how I can drill down with the debug?
I have lines added to .procmailrc to detect what rules are being used. This is my entry section to the file: # http://pm-doc.sourceforge.net/doc/#variables_used_in_recipes # Pure newline NL = " " TODAYISO = `date '+%Y-%m-%d %H:%M:%S.%N%:z'` #TODAY = `date '+%Y-%m-%d'` #THISMONTH = `date '+%Y-%m'` THISWEEK = `date '+%Y-%m_%W'` DELIVER = "/usr/lib/dovecot/dovecot-lda" FORMAIL = "/usr/bin/formail" :0 h * ^Message-ID: MESSAGEID=| $FORMAIL -c -xMessage-ID: LOG="$NL+++----> EMPEZANDO REGISTRO $TODAYISO (msgid: $MESSAGEID) $NL" dummy = "you can use this dummy to tell things on the log - when verbose is on" much later: VERBOSE=off :0 * some rule { LOG="REGISTRANDO: seccion de tesa lists en proceso de cambio para usar dovecot-lda $NL" VERBOSE=on dummy = "Changing section to use DELIVER - zap_spam_tesa_lists" :0f # Aquí se producía un gran retraso, porque el lockfile estaba arriba en vez de abajo. # Todos los correos se chequean y esperaban de uno en uno durante el spamc, aunque luego no haya que moverlos porque no son spam. # deliver es rápido, spamc no. | /usr/bin/spamc -s 25000000 :0 aw: $HOME/Mail/.D-locks/zap_spam_tesa_lists.lock * ^X-Spam-Status: Yes # Esta linea siguiente estaba generando archivado en formato maildir del spam! En ~/Mail/new #$HOME/Mail/ zap_spam_tesa_lists | $DELIVER -m zap_spam_tesa_lists #in_spam_tesa2 VERBOSE=off The first comment applies to you. I'll translate. There was a big delay here, because the lockfile was above, not below. All posts are tested, and waited one by one during spamc, even though they don't have to be moved because they are not spam. deliver is fast, spamc is not. Ie, the placement of your "/tmp/spamassassin.lock" is wrong. Also, I would not use /tmp for this, being a global placement. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 07/22/2016 02:35 PM, Carlos E. R. wrote:
Ie, the placement of your "/tmp/spamassassin.lock" is wrong. Also, I would not use /tmp for this, being a global placement.
*sigh* Once again, I have not posted *all* of my .procmailrc. back when I set this up I find arguments both sides about that. What I didn't post was the stack of comment lines about what I did post. I'll - again for brevity - post ONE of them here: # The lock file ensures that only 1 spamassassin invocation happens # at 1 time, to keep the load down If you have an argument against that reasoning, which was in the rc file I snarfed from the net, but don't recall where and can't find it in my notes since that far back is not to hand, then please detail them. However spamassassin works for the other cases; I'm just not seeing the 'blacklist_from' being carried out. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-07-22 21:33, Anton Aylward wrote:
On 07/22/2016 02:35 PM, Carlos E. R. wrote:
Ie, the placement of your "/tmp/spamassassin.lock" is wrong. Also, I would not use /tmp for this, being a global placement.
*sigh* Once again, I have not posted *all* of my .procmailrc. back when I set this up I find arguments both sides about that.
What I didn't post was the stack of comment lines about what I did post. I'll - again for brevity - post ONE of them here:
# The lock file ensures that only 1 spamassassin invocation happens # at 1 time, to keep the load down
Well, if that's what you want, then yes. Do it. It will process email very slowly, though. I have about a dozen.
However spamassassin works for the other cases; I'm just not seeing the 'blacklist_from' being carried out.
Yes, strange. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 07/22/2016 02:35 PM, Carlos E. R. wrote:
On 2016-07-22 14:38, Anton Aylward wrote:
I have some "blacklist_from" entries in my .spamassassin/user_prefs
blacklist_from *@sendio.pl blacklist_from *@supermailito.pl
The syntax is correct. I have entries in the same style.
and procmail pipes to spamassassin
:0 fw: /tmp/spamassassin.lock * < 256000 | /usr/bin/spamc
Here I do it differently:
:0fw | /usr/bin/spamc -s 25000000 :0 aw: $HOME/Mail/.D-locks/zap_spam_coitt.lock * ^X-Spam-Status: Yes | $DELIVER -m zap_spam_coitt
In the interests of brevity, I omitted the 120 lines (including comments) or my post spamassassin processing. I categorize how many "*" there are 10, 20, 30, 40, 50 ... the degree of spam-ness. Some of the some false positives in the [10,20] and some of the [45,50] deserve black listing. Either way, it has, in teh past, let me better tune the ratings.
I can add debug to my .procmail but that doesn't let me see the working *within* spamassassin. All I can see it how it rates SPAM, not what it does with blacklist items.
Are you sure that mail is being passed to spamc?
The best way I can answer that is to say that yes, the [10..50] are getting updated, or at least the timestamps on those files are recent.
Any idea how I can drill down with the debug?
I have lines added to .procmailrc to detect what rules are being used. This is my entry section to the file:
# http://pm-doc.sourceforge.net/doc/#variables_used_in_recipes [...]
Yes and more. I've no problems with debugging the procmail side of things. The problem is that a) some of these are foreign language and even before passing to spamc I try filtering those out by looking for the 'charset' in the header. Some Polish sites don't make use of that So my procmail stanzas for weeding out different font messages before making use of spamassassin do not work. b) if spamassassin was working properly these would be blacklisted - I take that to mean 'disappeared'. Am I wrong in that assumption? Should I bee looking for some special tag? c) I don't know how to debug *WITHIN* spamassassin -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-07-22 22:55, Anton Aylward wrote:
On 07/22/2016 02:35 PM, Carlos E. R. wrote:
Yes and more. I've no problems with debugging the procmail side of things.
The problem is that a) some of these are foreign language and even before passing to spamc I try filtering those out by looking for the 'charset' in the header.
Some Polish sites don't make use of that
So my procmail stanzas for weeding out different font messages before making use of spamassassin do not work.
I sometimes create my own SA rules.
b) if spamassassin was working properly these would be blacklisted - I take that to mean 'disappeared'. Am I wrong in that assumption? Should I bee looking for some special tag?
I never automatically delete spam, just in case the processing works bad.
c) I don't know how to debug *WITHIN* spamassassin
You have to carefully examine the headers of the processed email. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
On 07/22/2016 08:15 PM, Carlos E. R. wrote:
On 2016-07-22 22:55, Anton Aylward wrote:
On 07/22/2016 02:35 PM, Carlos E. R. wrote:
Yes and more. I've no problems with debugging the procmail side of things.
The problem is that a) some of these are foreign language and even before passing to spamc I try filtering those out by looking for the 'charset' in the header.
Some Polish sites don't make use of that
So my procmail stanzas for weeding out different font messages before making use of spamassassin do not work.
I sometimes create my own SA rules.
I make a LOT of procmail rules and my user_prefs runs to 15k; about 2/3rs of it is new rules and weightings. That's not the point. Other than success/fail I can't see how to debug a blacklist_from in SA.
c) I don't know how to debug *WITHIN* spamassassin
You have to carefully examine the headers of the processed email.
SA seems to be passing these polish-domain spam messages though unchanged. A few but not all get caught on other rules, pegged about 6.8. my trigger is 5. The ones that get though AND the ones that get 6.8 *should* have been caught by the blacklist_from. They weren't. Neither type had anything in the headers that indicated they had been blacklisted. I ask once again, what does 'blacklist_from" result in? Should it silently delete? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-07-23 13:17, Anton Aylward wrote:
On 07/22/2016 08:15 PM, Carlos E. R. wrote:
So my procmail stanzas for weeding out different font messages before making use of spamassassin do not work.
I sometimes create my own SA rules.
I make a LOT of procmail rules and my user_prefs runs to 15k; about 2/3rs of it is new rules and weightings.
That's not the point.
Other than success/fail I can't see how to debug a blacklist_from in SA.
Do you use bayes? (on SA). I use very few blacklist entries, bayes filters catches most of the spam here.
c) I don't know how to debug *WITHIN* spamassassin
You would have to play with the perl code, I think.
You have to carefully examine the headers of the processed email.
SA seems to be passing these polish-domain spam messages though unchanged. A few but not all get caught on other rules, pegged about 6.8. my trigger is 5. The ones that get though AND the ones that get 6.8 *should* have been caught by the blacklist_from. They weren't.
Maybe your user prefs file has some other syntax problem (you say the file is big) and it doesn't read the line.
Neither type had anything in the headers that indicated they had been blacklisted.
I ask once again, what does 'blacklist_from" result in? Should it silently delete?
No, SA will never delete. It just sets the score to 999, I think. I can't check right now, I have to reboot to another partition to have a look, and find examples. -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/23/2016 09:26 AM, Carlos E. R. wrote:
Maybe your user prefs file has some other syntax problem (you say the file is big) and it doesn't read the line.
Ah. I was sort-of-maybe about that. The whitelist/blacklist is early in the files, the weighting values and new rules come alter. The whitelist seems to be working but perhaps for another reason. I commented out the latter half and it worked, so went though step by step and found the syntax problem. Still puzzled about why the whitelist worked if the whole file aborted.
Neither type had anything in the headers that indicated they had been blacklisted.
I ask once again, what does 'blacklist_from" result in? Should it silently delete? No, SA will never delete. It just sets the score to 999, I think. I can't check right now, I have to reboot to another partition to have a look, and find examples.
Ah, found that. Now I'm seeing X-Spam-Report: * 999 USER_IN_BLACKLIST From: address is in the user's black-list Am happy camper now :-) -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-07-23 16:24, Anton Aylward wrote:
On 07/23/2016 09:26 AM, Carlos E. R. wrote:
Ah, found that. Now I'm seeing
X-Spam-Report: * 999 USER_IN_BLACKLIST From: address is in the user's black-list
Am happy camper now :-)
Good! :-) -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Anton Aylward wrote:
I ask once again, what does 'blacklist_from" result in? Should it silently delete?
No, spamassassin only scores the email, what you do with the score is entirely up to you. blacklisting will add 100 pts to the score. -- Per Jessen, Zürich (28.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/22/2016 04:55 PM, Anton Aylward wrote:
I categorize how many "*" there are 10, 20, 30, 40, 50 ... the degree of spam-ness. Some of the some false positives in the [10,20] and some of the [45,50] deserve black listing. Either way, it has, in the past, let me better tune the ratings.
Does anyone else do ratings / categorization by means of the 'score'? -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
* Anton Aylward <opensuse@antonaylward.com> [2016-07-23 06:26]:
On 07/22/2016 04:55 PM, Anton Aylward wrote:
I categorize how many "*" there are 10, 20, 30, 40, 50 ... the degree of spam-ness. Some of the some false positives in the [10,20] and some of the [45,50] deserve black listing. Either way, it has, in the past, let me better tune the ratings.
Does anyone else do ratings / categorization by means of the 'score'?
I sort the messages in to separate files depending on the SPAM score, e.g., I may have a file for anything between my non-SPAM cutoff to 10, one for 10+ thru 20, one for 20+ thru 30, etc., followed by a catchall file. The point is that I can check the lower-scored files for any false positives more easily since they will be smaller than without the sorting. I also tend to check the higher scored files less often. --Phil -- Philip Amadeo Saeli psaeli@zorodyne.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-07-23 13:26, Anton Aylward wrote:
On 07/22/2016 04:55 PM, Anton Aylward wrote:
I categorize how many "*" there are 10, 20, 30, 40, 50 ... the degree of spam-ness. Some of the some false positives in the [10,20] and some of the [45,50] deserve black listing. Either way, it has, in the past, let me better tune the ratings.
Does anyone else do ratings / categorization by means of the 'score'?
Score? No, how do you do that? -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/23/2016 08:52 PM, Carlos E. R. wrote:
On 2016-07-23 13:26, Anton Aylward wrote:
On 07/22/2016 04:55 PM, Anton Aylward wrote:
I categorize how many "*" there are 10, 20, 30, 40, 50 ... the degree of spam-ness. Some of the some false positives in the [10,20] and some of the [45,50] deserve black listing. Either way, it has, in the past, let me better tune the ratings.
Does anyone else do ratings / categorization by means of the 'score'?
Score? No, how do you do that?
Right now I do it by having multiple stanzas that count the number of asterisks: * ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\** { LOG="SPAMSCOREYES 20SPAM " :0: $JUNKBOX/20SPAM } for 10, 20, 30, 40, 50+ There must be a better way. Perhaps # Drop spam over score 50. :0 * ^X-Spam-Status: Yes, score=\/[0-9-]+ * ? test $MATCH -gt 50 $JUNKBOX/isSPAM But other than more step and repeat, I can't see how to minimise that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-07-24 14:17, Anton Aylward wrote:
On 07/23/2016 08:52 PM, Carlos E. R. wrote:
On 2016-07-23 13:26, Anton Aylward wrote:
On 07/22/2016 04:55 PM, Anton Aylward wrote:
I categorize how many "*" there are 10, 20, 30, 40, 50 ... the degree of spam-ness. Some of the some false positives in the [10,20] and some of the [45,50] deserve black listing. Either way, it has, in the past, let me better tune the ratings.
Does anyone else do ratings / categorization by means of the 'score'?
Score? No, how do you do that?
Right now I do it by having multiple stanzas that count the number of asterisks:
* ^X-Spam-Level: \*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\** { LOG="SPAMSCOREYES 20SPAM " :0: $JUNKBOX/20SPAM } for 10, 20, 30, 40, 50+
Ah, I see. Yes, I remember reading about this years ago, when I started setting it up. No, I don't bother, I trigger on yes/no, which is at the '5' score? Then I review the spam folder(s) to see if some "subject" line looks like not spam to verify. Nowdays i get very little spam, anyway. Gmail does a very good job. My ISP does a nosy job, because it refuses and deletes spam without asking. I thought you had a method to, in user prefs, define a score for an address, instead of an absolute "all email from this address is spam", giving a 999 score. That's why I have created some (perl?) rules of my own. With difficulty, I don't speak perl. -- Cheers / Saludos, Carlos E. R. (from openSUSE Leap 42.1 x86_64 (test)) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 07/24/2016 08:38 AM, Carlos E. R. wrote:
Ah, I see. Yes, I remember reading about this years ago, when I started setting it up. No, I don't bother, I trigger on yes/no, which is at the '5' score?
Then I review the spam folder(s) to see if some "subject" line looks like not spam to verify.
I agree with Philip when he says that categorization is a good tool:
The point is that I can check the lower-scored files for any false positives more easily since they will be smaller than without the sorting. I also tend to check the higher scored files less often.
The higher scored one are more likely to be blacklist (file as /dev/null) candidates. Yes, anything over 1,000 :-)
Nowdays i get very little spam, anyway. Gmail does a very good job. My ISP does a nosy job, because it refuses and deletes spam without asking.
I think GMail is nosy, more so than I want to deal with. I have about 40 email addresses in use,most of them single purpose, perhaps on specific mailing lists or groups of vendors. My @antonaylward ISP, Dreamhost, allows me (effectively) unlimited email addresses :-) It makes filtering and hence automation so much easier! It also means that if a vendor group turn Spammy I can simply cancel that email address. Most of the lists I'm on are closed and the archives are not publicly accessible. This is an exception to that latter one, and I get 4-5 piec3s of non-list related mail from spammers or peole making other solicitations each month. However one address I've had since the start of the 1990s and I get about 80-200 pieces of spam there EACH DAY! My tuned Procmail+Spamassassin has been taking care of that very well until recently. Now, thank you, that gap has been closed.
I thought you had a method to, in user prefs, define a score for an address, instead of an absolute "all email from this address is spam", giving a 999 score.
Yes, you can, but some sites don't have real users, that are spam only or advertising only. Do you really want email from casinos, non-prescription pharmaceuticals, sex slavers? http://winhelp2002.mvps.org/hostsfaq.htm http://www.hostsfile.org/downloads/hosts.txt Many others. Google for yourself.
That's why I have created some (perl?) rules of my own. With difficulty, I don't speak perl.
-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-07-24 15:32, Anton Aylward wrote:
On 07/24/2016 08:38 AM, Carlos E. R. wrote:
Ah, I see. Yes, I remember reading about this years ago, when I started setting it up. No, I don't bother, I trigger on yes/no, which is at the '5' score?
Then I review the spam folder(s) to see if some "subject" line looks like not spam to verify.
I agree with Philip when he says that categorization is a good tool:
The point is that I can check the lower-scored files for any false positives more easily since they will be smaller than without the sorting. I also tend to check the higher scored files less often.
The higher scored one are more likely to be blacklist (file as /dev/null) candidates. Yes, anything over 1,000 :-)
When you get about one spam mail per day, it is pointless :-) I'm more interested to know to which account it was sent, so I classify on that (can't rely on the "To:" header).
Nowdays i get very little spam, anyway. Gmail does a very good job. My ISP does a nosy job, because it refuses and deletes spam without asking.
I think GMail is nosy, more so than I want to deal with.
Yes.
I have about 40 email addresses in use,most of them single purpose, perhaps on specific mailing lists or groups of vendors. My @antonaylward ISP, Dreamhost, allows me (effectively) unlimited email addresses :-) It makes filtering and hence automation so much easier!
It also means that if a vendor group turn Spammy I can simply cancel that email address.
Most of the lists I'm on are closed and the archives are not publicly accessible. This is an exception to that latter one, and I get 4-5 piec3s of non-list related mail from spammers or peole making other solicitations each month.
However one address I've had since the start of the 1990s and I get about 80-200 pieces of spam there EACH DAY! My tuned Procmail+Spamassassin has been taking care of that very well until recently. Now, thank you, that gap has been closed.
Not something we can all do ;-)
I thought you had a method to, in user prefs, define a score for an address, instead of an absolute "all email from this address is spam", giving a 999 score.
Yes, you can, but some sites don't have real users, that are spam only or advertising only. Do you really want email from casinos, non-prescription pharmaceuticals, sex slavers?
No. But sometimes one can get a spam post apparently from an address that I have whitelisted, because the spammer happened to use that address (faked). So I don't want the white list to be absolute. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Anton Aylward wrote:
c) I don't know how to debug *WITHIN* spamassassin
Run spamd with "-D<component>", that'll produce lots of debug info. -- Per Jessen, Zürich (28.8°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
Anton Aylward wrote:
c) I don't know how to debug *WITHIN* spamassassin
Run spamd with "-D<component>", that'll produce lots of debug info.
From "man spamd":
-D [area,...], --debug [area,...] Produce debugging output. If no areas are listed, all debugging information is printed. Diagnostic output can also be enabled for each area individually; area is the area of the code to instrument. For example, to produce diagnostic output on bayes, learn, and dns, use: spamassassin -D bayes,learn,dns For more information about which areas (also known as channels) are available, please see the documentation at: http://wiki.apache.org/spamassassin/DebugChannels -- Per Jessen, Zürich (19.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Anton Aylward -
Carlos E. R. -
Per Jessen -
Philip Amadeo Saeli