Re: bit.ly and Spamhaus DBL
On 05/03/2014 05:47, Benny Pedersen wrote: On 2014-03-04 18:52, Ben wrote: Just for my reference, is there a way to affect the score rather than skip completely ? score FOO (1) (1) (1) (1) add one point to FOO rule it also works with negative scores that will subtract scores post sample if more help is needed Thanks, will have a play around !
Re: bit.ly and Spamhaus DBL
On 3/5/2014 7:18 AM, Ben wrote: On 05/03/2014 05:47, Benny Pedersen wrote: On 2014-03-04 18:52, Ben wrote: Just for my reference, is there a way to affect the score rather than skip completely ? score FOO (1) (1) (1) (1) add one point to FOO rule it also works with negative scores that will subtract scores post sample if more help is needed Thanks, will have a play around ! By the way, I recommend you inform Spamhaus of the FP on bitly. I would have never put it on a blacklist to begin with, due to the overwhelming hammy use that already exists.
Re: bit.ly and Spamhaus DBL
On 03/05/2014 02:18 PM, Joe Quinn wrote: On 3/5/2014 7:18 AM, Ben wrote: On 05/03/2014 05:47, Benny Pedersen wrote: On 2014-03-04 18:52, Ben wrote: Just for my reference, is there a way to affect the score rather than skip completely ? score FOO (1) (1) (1) (1) add one point to FOO rule it also works with negative scores that will subtract scores post sample if more help is needed Thanks, will have a play around ! By the way, I recommend you inform Spamhaus of the FP on bitly. I would have never put it on a blacklist to begin with, due to the overwhelming hammy use that already exists. Joe, Their bit.ly entry is not an FP looks at the SA rules, read the DBL listing policy before proclaming the listing a FP.
Re: sa-update fails - bug 6702 reappearing? --- solved
Thanks a lot for this hint - that's been it! This had happened: The files /etc/mail/spamassassin/*.pre, that already existed, were not replaced by the new versions. Only the new file v340.pre was copied to /etc/mail/spamassassin. After moving the existing *.pre files somewhere else and copying the new *.pre files, sa-update worked without any problem. But now I'm wondering, why the *.pre files aren't included in /usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Mail/SpamAssassin/.packlist (and not included in the file list shown after make uninstall)? But that's another topic. (Sorry, that I couldn't come back to this topic earlier - many colleagues are ill and need substitution.) Best regards and many thanks, Dieter Am 04.03.2014 15:09, schrieb Mark Martinec: Dieter Braun wrote: # sa-update rules: failed to run T_HEADER_FROM_DIFFERENT_DOMAINS test, skipping: (Can't locate object method check_equal_from_domains via package Mail::SpamAssassin::PerMsgStatus at (eval 1008) line 97. You are missing a line: loadplugin Mail::SpamAssassin::Plugin::HeaderEval in one of your .pre files. That line is normally in v320.pre. You may have commented it out, or the file v320.pre is missing from your SpamAssassin configuration directory. Btw, the rule T_HEADER_FROM_DIFFERENT_DOMAINS should have been conditionalized to only apply if the plugin HeaderEval is available. Mark attachment: dieter_braun.vcf
Re: bit.ly and Spamhaus DBL
On Wed, 05 Mar 2014 08:18:39 -0500 Joe Quinn wrote: By the way, I recommend you inform Spamhaus of the FP on bitly. It's not an FP, Spamhaus lists it as a redirector, which it is. As has already been pointed-out it scores 0.001 in SA.
Re: sa-update fails - bug 6702 reappearing? --- solved
On 3/5/2014 8:36 AM, Dieter Braun wrote: Thanks a lot for this hint - that's been it! This had happened: The files /etc/mail/spamassassin/*.pre, that already existed, were not replaced by the new versions. Only the new file v340.pre was copied to /etc/mail/spamassassin. After moving the existing *.pre files somewhere else and copying the new *.pre files, sa-update worked without any problem. But now I'm wondering, why the *.pre files aren't included in /usr/lib/perl5/site_perl/5.8.8/x86_64-linux-thread-multi/auto/Mail/SpamAssassin/.packlist (and not included in the file list shown after make uninstall)? But that's another topic. User configuration files (.pre files are intended to be changed) are usually exempted to avoid removing important local configuration. The bug really was on our end where we were not testing all the plugins needed for that rule and you happened to have one of the two disabled. You just helped identify the bug. (Sorry, that I couldn't come back to this topic earlier - many colleagues are ill and need substitution.) Better health to them! regards, KAM
Re: SpamAssassin version 3.3.1 stop working with Illegal instruction
Guys, I've got trouble implementing whitelist in spam assassin, either 3.3.2 or 3.4.0 - with simscan and qmail. I started using whitelist couple of months before with 3.3.2 and it looked as if they were working - at least until last february 2014. I've implemented whitelist_from, whitelist_from_rcvd and its counterparts relays, all_spam_to, and score them to -100 (this with 3.4.0), but still some emails get quarantined. My conf file is /etc/mail/spamassassin/local.cf (trying to implement it globally). I understand the type of whitelist in spam assassin (whitelist, more_spam_to, all_spam_to), but I just couldn't get them to work as they should. How can I implement them correctly and ensure whether my spam assassin's installation is complete? Thank you for your help. Note: 3.3.2 version was installed using clan, 3.4.0 was with simple make/make install (can't got it to work with clan method - it won't make). I did as-update. Best regards, Mario
Re: bit.ly and Spamhaus DBL
On Mar 5, 2014, at 10:40 PM, Neil Schwartzman n...@cauce.org wrote: Yeah. An abused, and abusive redirector. They only deal with abuse Monday-Friday, 9:00-17:00.* They never break links, but put an interstitial in between the victim and the payload. Gee thanks. BTW spamhaus aren’t the only ones fed up with Bit.ly’s laconic attitude towards abuse. The URL you recently submitted has been accepted as a phishing site by Netcraft. URL: https://bit . ly/OZVosY
Re: bit.ly and Spamhaus DBL
On 3/5/2014 9:57 AM, Neil Schwartzman wrote: On Mar 5, 2014, at 10:40 PM, Neil Schwartzman n...@cauce.org wrote: Yeah. An abused, and abusive redirector. They only deal with abuse Monday-Friday, 9:00-17:00.* They never break links, but put an interstitial in between the victim and the payload. Gee thanks. BTW spamhaus aren’t the only ones fed up with Bit.ly’s laconic attitude towards abuse. The URL you recently submitted has been accepted as a phishing site by Netcraft. URL: https://bit . ly/OZVosY Today I learned! The original question was on reducing the weight of just the bit.ly URIBL score and I must have subconsciously inserted because it is an FP. Sorry for derailing the thread.
Re: bit.ly and Spamhaus DBL
On 5 Mar 2014 22:40:37 +0800 Neil Schwartzman wrote: On Mar 5, 2014, at 9:38 PM, RW rwmailli...@googlemail.com wrote: On Wed, 05 Mar 2014 08:18:39 -0500 Joe Quinn wrote: By the way, I recommend you inform Spamhaus of the FP on bitly. It's not an FP, Spamhaus lists it as a redirector, which it is. As has already been pointed-out it scores 0.001 in SA. Yeah. An abused, and abusive redirector. They only deal with abuse Monday-Friday, 9:00-17:00.* ... Which makes it all the odder to increase the score for URIBL_DBL_REDIR and then reduce it for bit.ly.
pyzor: check failed: internal error, python traceback seen in response
Howdy, I'm running SA on a RHEL 6.5 machine.
Using spamassassin-3.3.1-3.el6.x86_64, pyzor-0.5.0-3.el6.noarch,
spamass-milter-0.3.2-3.el6.x86_64 and milter-greylist-4.5.7-1.el6.x86_64
(if that matters).
The relevant parts of my sendmail.mc are:
INPUT_MAIL_FILTER(`spamassassin',
`S=unix:/var/run/spamass-milter/spamass-milter.sock, F=,
T=C:15m;S:4m;R:4m;E:10m')dnl
define(`confMILTER_MACROS_CONNECT',`t, b, j, _, {daemon_name},
{if_name},{if_addr}')dnl
INPUT_MAIL_FILTER(`greylist',`S=local:/var/run/milter-greylist/milter-greylist.sock')dnl
define(`confMILTER_MACROS_HELO', `{verify}, {cert_subject}')dnl
define(`confMILTER_MACROS_ENVFROM', `i, {auth_authen}')dnl
define(`confMILTER_MACROS_ENVRCPT', `b, r, v, Z, {greylist}')dnl
define(`confINPUT_MAIL_FILTERS', `spamassassin, greylist')
I set spamassassin to run as user spam:
[root@ns2 ~]# cat /etc/sysconfig/spamassassin
# Options to spamd
SPAMDOPTIONS=-u spam -d -c -m5 -H
I also set spamass-milter to run as spam:
[root@ns2 ]# grep RUN_AS_USER /etc/rc.d/init.d/spamass-milter
RUN_AS_USER=spam
...
I am seeing this in /var/log/maillog every time I start up SpamAssassin:
Mar 5 23:26:34 ns2 spamd[9065]: pyzor: check failed: internal error,
python traceback seen in response
I've done pyzor -discover as the spam user, and pyzor ping reports
everything is OK.
What am I doing wrong? Everything is, as far as I can tell, running as
spam.
Why am I getting an error in pyzor when SA starts up? Anyone know?
Thomas
