Re: sa-compile and backlashes
It's consistently interpreting escaped backslashes (\\) as either \" or \"", which screws re2c up because that creates an incorrect amount of "'s. I even tried escaping it has hex "\x52" (or whatever the right number was--don't have my ascii table handy anymore :). Sounds like opening a Bugzilla ticket would be a good idea. Loren
Re: sa-compile and backlashes
Loren Wilton wrote:
rule work, but the ones with the "\|\\\|" (matching "|\|") all choke:
"fro|\""|"{RET("__XM_Sft_Ms_Fp_L33T");}
It produces the above output, instead of "fro|\|". Not sure what it's
doing. Any solution other than commenting out the offending rules?
What version of re2c? There reports that version before version12
"have bugs".
The bugs aren't specified, but I assume they could include miscompiling
the regexes.
It's v0.12. I don't think it's re2c anyway--re2c is choking on it because
sa-compile is producing the above .re file. That line of the .re file
should start with "fro|\|", and if I manually edit it, it compiles fine.
It's consistently interpreting escaped backslashes (\\) as either \" or
\"", which screws re2c up because that creates an incorrect amount of "'s.
I even tried escaping it has hex "\x52" (or whatever the right number
was--don't have my ascii table handy anymore :).
--
Gus
Re: custom rules within user_prefs
Thanks, Matt and Loren for your responses. Since I'm hosting with a shared hosting environment company myself, I was asking those questions more on a hunt for information so I could suggest to my provider to allow it. But I definitely get Loren's warning about having performance issues if parsing takes 'too long'. And I don't see these guys being terribly proficient at (or excited about) tinkering with CPanel code since they don't give us SSH access. Guess I'll just deal with the default rules and keep training with sa-learn. Thanks again, Ian
Re: How To Kill Spam Dead?
From: "Justin Mason" <[EMAIL PROTECTED]>
Matt Kettler writes:
[lots of correct stuff]
...
Anyone telling you spammers only or mostly use bogus return addresses
either hasn't studied spam extensively or is deluding themselves.
Well, they *used* to use bogus addresses -- that was the case 2 or 3
years ago, before Sender Address Verification [1]. Since then, spam
generally uses randomly-chosen, "real" user addresses, as Matt says.
[1]: http://taint.org/2007/03/16/134743a.html
I've written my thoughts about C-R backscatter here: [2]
[2]: http://taint.org/2005/09/11/012434a.html
The only way I can see to have a NON-abusive challenge-response system
nowadays, would be to restrict challenges to domains for which the
challenged message passed SPF, Domain Keys or DKIM tests. (You'd still
annoy your correspondents, but at least you wouldn't be creating spam for
innocent third parties.)
None of the C-R filters bother doing that, though.
If I am replying to a sender's email and the sender is rude enough not
to let my reply through then "scroom".
Hey, Jo, come on over to my house for the !
Jo arrives. But the usual doorway transaction fails because a new
filter is in place that orders Joe to go back home and call from home
to say he's coming.
Scroom. I'd go home and stay home.
{^_^}
Re: custom rules within user_prefs
While I agree completely with Matt that user rules are in general pretty
safe, there is one more thing to be aware of. A badly-written regex can end
up being a DOS attack on SA itself, and by implication on the system and
mail processing path. Something with lots of * lengths and backtracking
could take minutes or hours to process if crafted carefully. Or even
carelessly by an idiot.
Since you are going through CPanel, perhaps you could put in something that
scans for and disallows * lengths in the allowed regexes, forcing people to
code {0,80} or whatever in place. That can still take a long time if
carefully mis-crafted, but in general will prevent well-meaning accidents.
Loren
Re: sa-compile and backlashes
rule work, but the ones with the "\|\\\|" (matching "|\|") all choke:
"fro|\""|"{RET("__XM_Sft_Ms_Fp_L33T");}
It produces the above output, instead of "fro|\|". Not sure what it's
doing. Any solution other than commenting out the offending rules?
What version of re2c? There reports that version before version12 "have
bugs".
The bugs aren't specified, but I assume they could include miscompiling the
regexes.
Loren
Re: custom rules within user_prefs
ian douglas wrote: > > "Note: if you use spamd, rules placed in user_prefs will be IGNORED by > default. If you add the allow_user_rules option to your local.cf you > can get spamd to honor them. However, before you enable it, you should > know that this is disabled by default for security reasons. In theory > a malicious local user might be able to exploit spamd with a clever > regex and gain root permissions. I know of no specific vulnerabilities > of this type in spamassassin at this time, but it is a possibility. > I'd only turn this on if you trust your local users not to try to hack > root." > > > I was curious whether the security implications as mentioned in the > wiki page referenced above have been addressed at all, and whether or > not it would be considered relatively 'safe' yet to let users write > their own SA rules within their user_prefs, or perhaps a compromise of > listing the individual users within the local.cf file instead of a > global "let everyone do it" setting? Realistically, it's pretty safe. I wrote that quite a long time ago (back in SA 2.43 days) I still know of no attack that would exploit this. Really this isn't about an real or known threat, it's about the fact that it's difficult to secure regular expressions in all possible cases. Lots of evil tricks can be done to create a regex that winds up invoking a shell script, etc. This is simply an "extra blanket" of security against these kinds of attacks. Over the years, spamd has also picked up an additional defense against this attack. It *never* scans mail while running as root, and if for some reason it is still running as root, it will setuid itself to nobody. You can't exploit spamd for root access through this vector unless it executes a poison regex while running as root. I would still advise keeping it off if you have highly untrustworthy users (ie: you're at defcon), especially if they have shell access too. However, if your users are just doing web configs, have no shell login, and aren't a particularly motley crew, you're probably safe enabling it. In short: keeping it on offers you extra security, but there are other mechanisms in place.
custom rules within user_prefs
Hi all, long-time SpamAssassin user. I released an open-source web-based training script for CPanel hosting users to train spam/ham based on various configurations, and it's been very well received with a handful of CPanel-based hosting groups that I've shown it to. Check out http://iandouglas.com/page.php?3 if anyone's interested. Introductions aside, I shut down my own hosting business in 2004 after 7 successful years, and now host a handful of domains with various CPanel-based hosting groups. I found this wiki reference today after searching around for how to let users write their own custom SA rules within user_prefs: http://wiki.apache.org/spamassassin/WritingRules "Note: if you use spamd, rules placed in user_prefs will be IGNORED by default. If you add the allow_user_rules option to your local.cf you can get spamd to honor them. However, before you enable it, you should know that this is disabled by default for security reasons. In theory a malicious local user might be able to exploit spamd with a clever regex and gain root permissions. I know of no specific vulnerabilities of this type in spamassassin at this time, but it is a possibility. I'd only turn this on if you trust your local users not to try to hack root." I was curious whether the security implications as mentioned in the wiki page referenced above have been addressed at all, and whether or not it would be considered relatively 'safe' yet to let users write their own SA rules within their user_prefs, or perhaps a compromise of listing the individual users within the local.cf file instead of a global "let everyone do it" setting? Thanks for any thoughts, -id
Re: POPAuth plugin & 3.20?
Henry Kwan wrote: Hi, I've been running the POPAuth plugin on 3.18 with good results but noticed that 3.20 seems to break it. I tried searching the wiki and didn't see an update to the plugin. Is one needed or did I fubar something during 3.18 to 3.20 upgrade? Am currently running CentOS 4.4 with Perl 5.85. Will update to CentOS 4.5 and Perl 5.8.8 soon. It's probably incompatible with 3.2. Checking into this and fixing it (along with some efficiency improvements) is listed on a post-it-note on display #4. Unfortunately paying jobs take a much higher priority right now. Daryl
POPAuth plugin & 3.20?
Hi, I've been running the POPAuth plugin on 3.18 with good results but noticed that 3.20 seems to break it. I tried searching the wiki and didn't see an update to the plugin. Is one needed or did I fubar something during 3.18 to 3.20 upgrade? Am currently running CentOS 4.4 with Perl 5.85. Will update to CentOS 4.5 and Perl 5.8.8 soon. Thanks.
Re: zen.spamhaus.org
Jerry Durand wrote: On Jun 1, 2007, at 11:54 AM, Richard Frovarp wrote: That's assuming you aren't using it intelligently. SA checks all received headers via Zen to see if they are in the SBL. PBL and XBL are only checked against last external header, via Zen. Ah, nobody mentioned that SA was only using a subset of Zen, I was talking about the people using Zen to scan ALL the headers and the body of the message. So, really, SA is just using the SBL subset of Zen to scan the headers. How about the body of the message? Everything I know that uses zen, uses a subset of it. It's a composite list, so that is pretty much a given. That's why I send the link to zen and the link to the page on SA TrustedRelays, to show you a scenario where one could use ALL of zen on a received header, rather than just the connecting relay (in a case where the connecting relay is Trusted). The body of a message is looked at by uri parsers and uses things like surbl,uribl,uri country, etc to score based on uris found in message bodies. I wouldn't use any of zen for that, but it's possible to do. Problem is you lump any host on an IP with other hosts sharing that same ip. In virtual hosting environment, there can be hundreds of sites on a single IP, so FPs are common doing this - except perhaps with SBL. -- Ken Anderson Pacific.Net
Re: zen.spamhaus.org
At 12:05 PM 6/1/2007, Rob McEwen wrote: Did you mean to say, "SBL is fine for that." ?? I was going by old info, my server's had a separate rule to use SBL-XBL for years, but since SA now uses pieces of Zen, I killed that rule. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand
Re: zen.spamhaus.org
Jerry, I think I'm in totally agreement with you, except when you said: >>"SBL-XBL is fine for that." SBL is fine for checking all the headers... but, per my original message, I think that, like PBL, XBL will trigger too many FPs when checked against all IPs in the headers, not just the sending server IP. Sure, the percent of XBL FPs generated wouldn't be nearly as high as PBL, but still too high! Did you mean to say, "SBL is fine for that." ?? Rob McEwen PowerView Systems [EMAIL PROTECTED]
Re: zen.spamhaus.org
On Jun 1, 2007, at 11:54 AM, Richard Frovarp wrote: That's assuming you aren't using it intelligently. SA checks all received headers via Zen to see if they are in the SBL. PBL and XBL are only checked against last external header, via Zen. Ah, nobody mentioned that SA was only using a subset of Zen, I was talking about the people using Zen to scan ALL the headers and the body of the message. So, really, SA is just using the SBL subset of Zen to scan the headers. How about the body of the message?
Re: sa-compile and backlashes
Gus wrote:
Sorry if this has come up at all, but I have a few rules that sa-compile
chokes on. Wondering if there's a way around it...
Here's an example.
Original rule:
/(?:fr(?:o|0|\(\))(?:n|\|\\\|)[EMAIL PROTECTED])/i
Sa-compile seems to interpret every branch of this, so we end up with
multiple regex's in the scanner#.re files. Some branches of the above
rule work, but the ones with the "\|\\\|" (matching "|\|") all choke:
"fro|\""|"{RET("__XM_Sft_Ms_Fp_L33T");}
It produces the above output, instead of "fro|\|". Not sure what it's
doing. Any solution other than commenting out the offending rules?
Even escaping the ascii code for a backslash produces the above output.
Weird...
This doesn't fix the misinterpretation, but for the time being I've
replaced re2c with a wrapper script that first runs some sed
substitutions to fix the scanner#.re files, then runs re2c.
--
Gus
Re: zen.spamhaus.org
Jerry Durand wrote: On Jun 1, 2007, at 9:48 AM, Ken A wrote: see http://www.spamhaus.org/zen/ Quote from that page: "Do not use ZEN in filters that do any ‘deep parsing’ of Received headers, or for other than checking IP addresses that hand off to your mailservers." That's assuming you aren't using it intelligently. SA checks all received headers via Zen to see if they are in the SBL. PBL and XBL are only checked against last external header, via Zen.
Re: zen.spamhaus.org
On Jun 1, 2007, at 10:03 AM, Rob McEwen wrote: Now, if you want to use SBL-XBL, that's fine (I do). "Normal" users on dynamic addresses don't show up on those lists. I disagree. True for SBL, but not for XBL. Consider that there are MANY situations where a small-to-large office will all share an IP to the outside world. Maybe we are talking about 10 computers... maybe 100... maybe 1000+. All it takes is a single computer getting a zombie (and this wouldn't be all that rare... even if the I.T. guy was really good as his/her job!). Once one such computer gets a zombie... then that IP can easily get listed on XBL. But, that would be an address like the server I'm sitting at now, 192.168.0.13, are you going to blacklist EVERY person using 192.168.0.13 on an internal network? Look at the headers from another of my messages, it went through several hops before apache.org ever saw it, and I send it directly from the server. Apache.org SHOULD be using zen or something like it to verify the server talking to it, but how would Zen identify my computer on a subnet talking to my server which then goes through a NAT and then to verizon.net with SMTP AUTH and THEN to apache.org? Even if you go one server back from verizon.net, you'll find smpt.interstellar.com is on a dynamic address and is in the Zen list as such. Why is that a problem? Received: from [206.46.252.48] (HELO vms048pub.verizon.net) (206.46.252.48) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 01 Jun 2007 11:42:28 -0700 Received: from smtp.interstellar.com ([71.116.65.245]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <[EMAIL PROTECTED]> for users@spamassassin.apache.org; Fri, 01 Jun 2007 13:41:48 -0500 (CDT) Received: from localhost (localhost [127.0.0.1]) by smtp.interstellar.com (Postfix) with ESMTP id 4F70B3F06DF; Fri, 01 Jun 2007 11:41:47 -0700 (PDT) Received: from smtp.interstellar.com ([127.0.0.1]) by localhost (interstellar.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29L9yyuekAz6; Fri, 01 Jun 2007 11:41:46 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by smtp.interstellar.com (Postfix) with ESMTP id 93A373F06D5; Fri, 01 Jun 2007 11:41:45 -0700 (PDT) Another common scenario is that the end user's computer's IP often gets placed somewhere in the header by the SMTP server that they use for sending their legit e-mail. I think that this happens more often than not. So here you have a fairly common situation where MANY outgoing non spam legit e-mails have an XBL-listed IP somewhere in the header, but with the actual sending mail server is NOT listed on any spam blacklists because it simply doesn't send spam. Exactly, so if you use Zen to scan the headers, you'll get false positives all over the place. Suppose also that this expoited computer is not yet spotted and persists for weeks. In such a scenario, if ALL spam filters ONLY checked the actual sending server's IP, then ALL of the spam sent from this exploited computer would easily be caught... and ALL of the legit messages sent by that legit e-mail server from users in this office would NOT be mistakenly blocked... Seems that before weeks went by, the top server (in our case verizon.net) would get blacklisted and they'd be talking to us pretty quickly. ...a perfect world... ...but checking against OTHER IP addresses in the header messes this all up. Right, so per the warning on the Zen web page, do NOT use Zen for scanning the headers or body of the mail. SBL-XBL is fine for that.
Re: How to avoid filtering twice when having mail-groups
Manu wrote: > Great, that's what I want. > Currently my .qmail-Files look like this: > > | /opt/psa/bin/psa-spamc accept > | preline /usr/bin/procmail -m -o .procmailrc > > So I have to insert a line before the first line, right? I have no idea. I'm a sendmail+procmail guy. > Would you be so kind > to help me a bit? :) Well, here's a starting point for procmail-based processing. Note that I haven't checked this to actually be correct procmail syntax, or that it's logically correct.I'm pretty sure it should work the way you're looking for, however. In /etc/procmailrc: :0fw | spamassassin :0fw * ^From:[EMAIL PROTECTED] | formail -a "X-my-special-header: PTHBTT" Then in the individual .procmailrc files: :0fw * !^X-my-special-header: PTHBTT | spamassassin Munge to taste; man procmail, man procmailrc and man procmailex should be useful references. If your SA calls are happening somewhere else, you'll have to work out what sort of syntax you need to add an arbitrary header on messages from a certain source, and then not call per-user SA for messages that have that header added. -kgd
Re: zen.spamhaus.org
On Jun 1, 2007, at 9:48 AM, Ken A wrote: see http://www.spamhaus.org/zen/ Quote from that page: "Do not use ZEN in filters that do any ‘deep parsing’ of Received headers, or for other than checking IP addresses that hand off to your mailservers."
Re: sa-compile and sa-update
Pete 'Wolfy' Hanson wrote: Should I re-run sa-compile after a rules update by sa-update? Yes.
sa-compile and sa-update
Should I re-run sa-compile after a rules update by sa-update? -- Pete Hanson http://www.well.com/user/wolfy http://www.fotolog.net/wolfy
Re: zen.spamhaus.org
> Now, if you want to use SBL-XBL, that's fine (I do). "Normal" users on > dynamic addresses don't show up on those lists. I disagree. True for SBL, but not for XBL. Consider that there are MANY situations where a small-to-large office will all share an IP to the outside world. Maybe we are talking about 10 computers... maybe 100... maybe 1000+. All it takes is a single computer getting a zombie (and this wouldn't be all that rare... even if the I.T. guy was really good as his/her job!). Once one such computer gets a zombie... then that IP can easily get listed on XBL. Another common scenario is that the end user's computer's IP often gets placed somewhere in the header by the SMTP server that they use for sending their legit e-mail. I think that this happens more often than not. So here you have a fairly common situation where MANY outgoing non spam legit e-mails have an XBL-listed IP somewhere in the header, but with the actual sending mail server is NOT listed on any spam blacklists because it simply doesn't send spam. Suppose also that this expoited computer is not yet spotted and persists for weeks. In such a scenario, if ALL spam filters ONLY checked the actual sending server's IP, then ALL of the spam sent from this exploited computer would easily be caught... and ALL of the legit messages sent by that legit e-mail server from users in this office would NOT be mistakenly blocked... ...a perfect world... ...but checking against OTHER IP addresses in the header messes this all up. Rob McEwen PowerView Systems [EMAIL PROTECTED]
Re: zen.spamhaus.org
Jerry Durand wrote: At 08:47 AM 6/1/2007, Ken A wrote: Jerry Durand wrote: On Jun 1, 2007, at 6:48 AM, Luis Hernán Otegui wrote: Search through the archives, there was a patch to add it to SA. Also note, do NOT use Zen to evaluate headers or anything in the body. Unless of course you need to. ;-) http://wiki.apache.org/spamassassin/TrustedRelays Ken Not sure how you'd use Zen for this, since it lists all dynamic addresses as bad. see http://www.spamhaus.org/zen/ Internic tried this and was rejecting mailing lists based on submissions from people on dynamic addresses (like me) even though it was relayed through a trusted sender with AUTH. Now, if you want to use SBL-XBL, that's fine (I do). "Normal" users on dynamic addresses don't show up on those lists. -- Ken Anderson Pacific.Net
Re: zen.spamhaus.org
At 08:47 AM 6/1/2007, Ken A wrote: Jerry Durand wrote: On Jun 1, 2007, at 6:48 AM, Luis Hernán Otegui wrote: Search through the archives, there was a patch to add it to SA. Also note, do NOT use Zen to evaluate headers or anything in the body. Unless of course you need to. ;-) http://wiki.apache.org/spamassassin/TrustedRelays Ken Not sure how you'd use Zen for this, since it lists all dynamic addresses as bad. Internic tried this and was rejecting mailing lists based on submissions from people on dynamic addresses (like me) even though it was relayed through a trusted sender with AUTH. Now, if you want to use SBL-XBL, that's fine (I do). "Normal" users on dynamic addresses don't show up on those lists. -- Jerry Durand, Durand Interstellar, Inc. www.interstellar.com tel: +1 408 356-3886, USA toll free: 1 866 356-3886 Skype: jerrydurand
Re: Spam from own domain
(1) As was said earlier, but in greater detail: tell your MTA to look at the SMTP client's IP address, and trust (do not give to SA) any mail where the client IP address is in your local network(s) (this is the best solution), or (2) Modify the above to check your local network IP range(s), and include your MTA name as well. For example: Received =~ from .* \[192\.168\.100\.\d+\].* by ga\.impsec\.org (where ga.impsec.org is my MTA and 192.168.100.x is my local network) In order to bypass this a forger would need to know both your MTA's system name and your local network IP range(s). Hi John! I learned postfix already to reject unknown sender - works pretty good. Thanks for the hint! To the RCVD issue - I looked trough many incoming mails and discovered that every Received header line contains "rk-lilienfeld.at" (at least the first Received contains my Mailadress and rk-lilienfeld.at) ... I am almost a newbie at spam prevention with postfix/amavis/spamassassin but my thought upon that is that this rule affects every mail (which possible is completly wrong) lg martin
Re: zen.spamhaus.org
Jerry Durand wrote: On Jun 1, 2007, at 6:48 AM, Luis Hernán Otegui wrote: Search through the archives, there was a patch to add it to SA. Also note, do NOT use Zen to evaluate headers or anything in the body. Unless of course you need to. ;-) http://wiki.apache.org/spamassassin/TrustedRelays Ken Zen is ONLY for approving the server that contacted your server. See the notes on the Spamhaus.org web page. -- Ken Anderson Pacific.Net
Re: How to avoid filtering twice when having mail-groups
Kris Deugau wrote: > > I'm using SpamAssassin 3.0.2 and Qmail on a Debian Sarge Server. > > Administrative hosting panel is Plesk 8.1. > > Between qmail and Plesk, what you're looking for may not be possible > with the obvious exposed controls; you may need to manually dig into > configuration files to get the behaviour you want. No problem. Filtering is done by my own script which reads the Plesk-data. > On systems I'm responsible for (all currently SA3.1.8 + sendmail with no > formal "hosting panel"), I'd add a header during the "systemwide" scan, > and then check for that header during the per-user processing. If the > header was present, don't call SA again. Great, that's what I want. Currently my .qmail-Files look like this: | /opt/psa/bin/psa-spamc accept | preline /usr/bin/procmail -m -o .procmailrc So I have to insert a line before the first line, right? Would you be so kind to help me a bit? :) Thanks! -- Regards, Manu
Re: Spam from own domain
On Fri, 1 Jun 2007, Martin Hochreiter wrote: > I have the following option in the local.cf > > header LOCAL_RCVD Received =~ /\S+\.rk-lilienfeld\.at\s+\(.*\[.*\]\)/ > score LOCAL_RCVD -500 > > How can I ensure that at least mails from our local clients are > automatically whitelisted? (1) As was said earlier, but in greater detail: tell your MTA to look at the SMTP client's IP address, and trust (do not give to SA) any mail where the client IP address is in your local network(s) (this is the best solution), or (2) Modify the above to check your local network IP range(s), and include your MTA name as well. For example: Received =~ from .* \[192\.168\.100\.\d+\].* by ga\.impsec\.org (where ga.impsec.org is my MTA and 192.168.100.x is my local network) In order to bypass this a forger would need to know both your MTA's system name and your local network IP range(s). -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- In 1998 more than three times as many people in the US were killed by incompetent physicians than were killed by handguns, yet the President of the A.M.A. is adopting "gun safety" as his platform. --- 522 days until the Presidential Election
sa-compile and backlashes
Sorry if this has come up at all, but I have a few rules that sa-compile
chokes on. Wondering if there's a way around it...
Here's an example.
Original rule:
/(?:fr(?:o|0|\(\))(?:n|\|\\\|)[EMAIL PROTECTED])/i
Sa-compile seems to interpret every branch of this, so we end up with
multiple regex's in the scanner#.re files. Some branches of the above
rule work, but the ones with the "\|\\\|" (matching "|\|") all choke:
"fro|\""|"{RET("__XM_Sft_Ms_Fp_L33T");}
It produces the above output, instead of "fro|\|". Not sure what it's
doing. Any solution other than commenting out the offending rules?
--
Gus
Re: zen.spamhaus.org
On Jun 1, 2007, at 6:48 AM, Luis Hernán Otegui wrote: Search through the archives, there was a patch to add it to SA. Also note, do NOT use Zen to evaluate headers or anything in the body. Zen is ONLY for approving the server that contacted your server. See the notes on the Spamhaus.org web page.
Re: zen.spamhaus.org
Thanks, I will search for it. Am Freitag, den 01.06.2007, 10:50 -0300 schrieb Luis Hernán Otegui: > Or, if you could, upgrade to SA 3.2, which includes it. > > > Luix > > 2007/6/1, Martin Jürgens <[EMAIL PROTECTED]>: > > Hi, > > I am running Debian Etch, Exim4 and Spamassassin 3.1.7. > > > > Now I am trying to find out how to make Spamassassin use Spamhaus Zen. > > > > I am stuck. > > > > Could anyone please tell me what I have to add to my local.cf in order > > to use it? > > > > Thanks! > > > > Martin > > > > > >
Re: Fwd: how to move user_prefs path
Pradeep Mishra wrote:
> Dear All
>
> I have ovserved that iostat on one of my servers running spamassassin
> is aprox 12% and when i moved $Home/.spamassassin to somewhere else it
> comes down to 2%. I would like to know where can i change the path to
> /somehere/.spamassassin ??
> OR How do i change the userstate_dir path to
> /something_else/.spamassassin in place of /$USER_DIR/.spamassassin.
I found symlinking a user's ~/.spamassassin directory to somewhere else
works just fine.
Here's a shell script I wrote to do this. Modify to suit your system:
#!/bin/sh
# Move user's SA config from /home/{user}/.spamassassin to
# /var/SpamAssassin/{user}
nul=""
case "$1" in
$nul)
echo "usage: move-sa-user [user]"
echo " Username is REQUIRED"
exit 1;
;;
*)
mkdir /var/SpamAssassin/$1
mv /home/$1/.spamassassin/* /var/SpamAssassin/$1/
rm -rf /home/$1/.spamassassin/
ln -s /var/SpamAssassin/$1 /home/$1/.spamassassin
chown -R $1:mail_pop_only /var/SpamAssassin/$1
chown $1:mail_pop_only /home/$1/.spamassassin
echo "User's SA config moved."
;;
esac
Re: How to avoid filtering twice when having mail-groups
Manu wrote: > I'm using SpamAssassin 3.0.2 and Qmail on a Debian Sarge Server. > Administrative hosting panel is Plesk 8.1. Between qmail and Plesk, what you're looking for may not be possible with the obvious exposed controls; you may need to manually dig into configuration files to get the behaviour you want. > Imagine the following situation: > [EMAIL PROTECTED] forwards to [EMAIL PROTECTED], [EMAIL PROTECTED],... > > Now if SpamAssassin checks [EMAIL PROTECTED] and each user has enabled spam > filtering too, SpamAssassin will filter the same message once for mailgroup@ > and then once again for each user. We'll get: 1 + #users scans. > If I disable scanning of mailgroup@, we'll get #user scans for the very same > message. > > What I would like to have: SpamAssassin scans for mailgroup@ and when the > very > same message has to be scanned for each user, SpamAssassin remembers that > this message has already been scanned seconds ago and doesn't scan it again. SA doesn't have any sort of capability like that itself; it scans what it's been handed. On systems I'm responsible for (all currently SA3.1.8 + sendmail with no formal "hosting panel"), I'd add a header during the "systemwide" scan, and then check for that header during the per-user processing. If the header was present, don't call SA again. I'm pretty sure what you want is *possible*... but I can't say whether it's possible via your hosting panel, *easy* but you have to dig into back-end configuration files, or possible but bury-your-head-in-MTA-guts *nasty* to set up. -kgd
Re: zen.spamhaus.org
Search through the archives, there was a patch to add it to SA. Luix 2007/6/1, Martin Jürgens <[EMAIL PROTECTED]>: Hi, I am running Debian Etch, Exim4 and Spamassassin 3.1.7. Now I am trying to find out how to make Spamassassin use Spamhaus Zen. I am stuck. Could anyone please tell me what I have to add to my local.cf in order to use it? Thanks! Martin -- - GNU-GPL: "May The Source Be With You... Linux Registered User #448382. When I grow up, I wanna be like Theo... -
zen.spamhaus.org
Hi, I am running Debian Etch, Exim4 and Spamassassin 3.1.7. Now I am trying to find out how to make Spamassassin use Spamhaus Zen. I am stuck. Could anyone please tell me what I have to add to my local.cf in order to use it? Thanks! Martin signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Fwd: how to move user_prefs path
Pradeep Mishra wrote: > Dear All > > I have ovserved that iostat on one of my servers running spamassassin > is aprox 12% and when i moved $Home/.spamassassin to somewhere else it > comes down to 2%. I would like to know where can i change the path to > /somehere/.spamassassin ?? If it's IO, it's probably the bayes and AWL. Those can be changed using bayes_path and auto_whitelist_path settings at the local.cf level. WARNING: despite their names, these options are not just paths. bayes takes a path plus a partial filename that it will append _toks, _seen, etc to. The AWL one takes a path and a filename. However, unless this path is in ~/ you'll loose per-user state for these files, causing them all to be shared.. That might or might not be OK with you. see man Mail::SpamAssassin::Conf for more details. > OR How do i change the userstate_dir path to > /something_else/.spamassassin in place of /$USER_DIR/.spamassassin. If you use spamd, you can use the --virtual-config-dir option, to use SA data in some completely different path. This also allows %l to be specified to generate per-user directories. ie: --virtual-config-dir /vhome/%l/.spamaassassin see man spamd for more details
Fwd: how to move user_prefs path
Dear All I have ovserved that iostat on one of my servers running spamassassin is aprox 12% and when i moved $Home/.spamassassin to somewhere else it comes down to 2%. I would like to know where can i change the path to /somehere/.spamassassin ?? OR How do i change the userstate_dir path to /something_else/.spamassassin in place of /$USER_DIR/.spamassassin. Thanks Bye -- Forwarded message -- From: Pradeep Mishra <[EMAIL PROTECTED]> Date: Jun 1, 2007 1:41 AM Subject: how to move user_prefs path To: users@spamassassin.apache.org Dear All I have ovserved that iostat on one of my servers running spamassassin is aprox 12% and when i moved $Home/.spamassassin to somewhere else it comes down to 2%. I would like to know where can i change the path to /somehere/.spamassassin ?? Thanks in advance. -- Good Judgement comes from Experience and Experience comes from bad Judgement!! The more I know, the more I realize I don't know!? The easiest way to find out is to try it!!! -- Good Judgement comes from Experience and Experience comes from bad Judgement!! The more I know, the more I realize I don't know!? The easiest way to find out is to try it!!!
Re: Bayes combining and OCR (Was Re: SpamAssassin 3.2 compatiblity)
Justin Mason wrote: Matthias Keller writes: Nix wrote: On 31 May 2007, Graham Murray said: Nix <[EMAIL PROTECTED]> writes: (And, let's be blunt, the pure this-word-is-spammy recognition part of FuzzyOCR is much less smart than the Bayesian system already present in SA: FuzzyOCR should really use the Bayesian system to determine the spamminess of words, I suppose...) Or even just act as a MIME part 'decoding' system (like Base64) and feed all words it finds in images into Bayes, along with all other text in the mail, rather than generating a score itself. Perhaps so, but if so those words should have a score-multiplier of some sort applied, because the fact that those words originated in images is itself an obfuscation technique that should be noted in the score. This has been discussed here again and again and again first of all, these 10 words found in an image cannot stand against the bayes poisoning found in all these messages - so it would literally be useless for bayes filtering by the way, this is a common misconception of how our Bayes system works; what *should* happen is that the "poison" text winds up with "weak" Bayesian probability scores between 0.2 and 0.8, since it uses words that also appear in ham (hence why it appears as poison). However, the OCR'd text would wind up with "strong" scores around 0.99 or greater. The chi-square probability combining algorithm we use takes care of this, by discounting the "weak" clues and taking more account of the "strong" clues. (This is what makes it a more effective combining algorithm for Bayes than the traditional Graham style.) Would be nice if that worked - just it doesn't for me. I dont know how the algorithm works but I observed its results... I learnt dozens of spams with nearly identical spam texts (and only the spam stuff, not the poisoning) and an identical mail WITH random text got a Bayes 0.500 - hence really - it just doesn't work for me... Matt
RE: Installing 3.20 in FreeBSD
> -Original Message- > From: LuKreme [mailto:[EMAIL PROTECTED] > Sent: Friday, June 01, 2007 3:17 AM > To: users@spamassassin.apache.org > Subject: Installing 3.20 in FreeBSD > > > OK, so I downloaded the test sa320.tgz file and followed the > instructions and when I go to make I get: > > NOTE: the optional libnet module is not installed. > > Trouble is, libnet11-1.1.2.1_1,1 is installed. I even deleted it and > reinstalled it. You should do a ports tree update (portsnap , cvs) then check the dependencies again. Even though ports is 'half frozen' they did make some major updates to core dependencies on May 24th. Libnet might be old one, and the new ports tree fixes the multiple problems with Compress (zlib, base, about 5 other modules) Also, go to support, search pr, search for [SECURITY] file, (look for patches for file 4.21) Look for patches for re2c (if you use sa-compile) look for patches for razor (if you use razor) > > I also get: > > NOTE: the optional Compress::Zlib module is installed, > but is not an up-to-date version. > > but according to ports, p5-Compress-Zlib-2.004 is current > But the dependencies might not be. > OK, so it's running, and libnet is not a big deal as I don't use > spamcop, but it seems weird to me. > _ This email has been scanned and certified safe by SpammerTrap(tm). For Information please see http://www.spammertrap.com _
Re: Spam from own domain
Jonas Eckerman schrieb: Martin Hochreiter wrote: How can I ensure that at least mails from our local clients are automatically whitelisted? Don't feed mail from local clients through SpamAssassin. That's what I want, but how to learn that spamassassin / amavis ?
Re: Spam from own domain
Martin Hochreiter wrote: > How can I ensure that at least mails from our local clients are > automatically whitelisted? Don't feed mail from local clients through SpamAssassin. (I guess you also could do this by giving a very low score for ALL_TRUSTED.) /Jonas -- Jonas Eckerman, FSDB & Fruktträdet http://whatever.frukt.org/ http://www.fsdb.org/ http://www.frukt.org/
Re: Mail::SpamAssassin::PerMsgStatus::finish "failing" after upgrade from 3.1.7 to 3.2.0
Thanks a lot Justin. This is a big relief. I was worried that SA may
fall apart on me today and this makes me feel a lot better.
Thank you!
Joe
Justin Mason wrote:
hi Joe -- yep, it is. In fact you should probably use the G_ flag
for calling a method in void context, can't recall which one that is ;)
--j.
Joe Flowers writes:
Thanks Justin. I am embedding Perl inside a C program, so I hope this is
still true. It used to return a non-NULL or at least the following call
used to always return a "count" of 1 and not 0 like it is now after the
SA upgrade.
count = perl_call_method("Mail::SpamAssassin::PerMsgStatus::finish",
(G_ARRAY|G_EVAL|G_KEEPERR));
Is your answer still the same?
Thanks a lot!
Joe
Justin Mason wrote:
hi Joe --
just ignore the return value of finish() -- it's a void method.
(note how it doesn't mention a return value in its POD doc ;)
--j.
Joe Flowers writes:
Hello Everyone,
I'm getting a weird error message that I have never gotten before over
several versions of SA. I just upgraded from "SpamAssassin version 3.1.7
running on Perl version 5.8.8" to "SpamAssassin version 3.2.0 running on
Perl version 5.8.8". Now, my calls to
Mail::SpamAssassin::PerMsgStatus::finish are "failing"; or at least, it
looks like their has been some change in the return values by finish().
I have been running this programming over many iterations of SA and this
is the first time I have run into such a problem.
This worries me a lot because from the docs
(http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_PerMsgStatus.html):
"
$status->finish ()
If you are using SpamAssassin in a persistent environment, or
checking many mail messages from one Mail::SpamAssassin factory, this
method should be called to ensure Perl's garbage collection will clean
up old status objects.
".
These calls "succeed" as usual:
Mail::SpamAssassin::PerMsgStatus::get_required_score
Mail::SpamAssassin::PerMsgStatus::get_score
Mail::SpamAssassin::PerMsgStatus::is_spam
Mail::SpamAssassin::PerMsgStatus::get_names_of_tests_hit
"succeeded".>
Any ideas please?
Joe
Re: Mail::SpamAssassin::PerMsgStatus::finish "failing" after upgrade from 3.1.7 to 3.2.0
hi Joe -- yep, it is. In fact you should probably use the G_ flag
for calling a method in void context, can't recall which one that is ;)
--j.
Joe Flowers writes:
> Thanks Justin. I am embedding Perl inside a C program, so I hope this is
> still true. It used to return a non-NULL or at least the following call
> used to always return a "count" of 1 and not 0 like it is now after the
> SA upgrade.
>
> count = perl_call_method("Mail::SpamAssassin::PerMsgStatus::finish",
> (G_ARRAY|G_EVAL|G_KEEPERR));
>
> Is your answer still the same?
>
> Thanks a lot!
>
> Joe
>
>
> Justin Mason wrote:
> > hi Joe --
> >
> > just ignore the return value of finish() -- it's a void method.
> > (note how it doesn't mention a return value in its POD doc ;)
> >
> > --j.
> >
> > Joe Flowers writes:
> >
> >> Hello Everyone,
> >>
> >> I'm getting a weird error message that I have never gotten before over
> >> several versions of SA. I just upgraded from "SpamAssassin version 3.1.7
> >> running on Perl version 5.8.8" to "SpamAssassin version 3.2.0 running on
> >> Perl version 5.8.8". Now, my calls to
> >> Mail::SpamAssassin::PerMsgStatus::finish are "failing"; or at least, it
> >> looks like their has been some change in the return values by finish().
> >>
> >> I have been running this programming over many iterations of SA and this
> >> is the first time I have run into such a problem.
> >>
> >> This worries me a lot because from the docs
> >> (http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_PerMsgStatus.html):
> >> "
> >> $status->finish ()
> >>
> >> If you are using SpamAssassin in a persistent environment, or
> >> checking many mail messages from one Mail::SpamAssassin factory, this
> >> method should be called to ensure Perl's garbage collection will clean
> >> up old status objects.
> >> ".
> >>
> >> These calls "succeed" as usual:
> >>
> >> Mail::SpamAssassin::PerMsgStatus::get_required_score
> >> Mail::SpamAssassin::PerMsgStatus::get_score
> >> Mail::SpamAssassin::PerMsgStatus::is_spam
> >> Mail::SpamAssassin::PerMsgStatus::get_names_of_tests_hit
> >> >> "succeeded".>
> >>
> >> Any ideas please?
> >>
> >> Joe
> >>
> >
> >
Re: Mail::SpamAssassin::PerMsgStatus::finish "failing" after upgrade from 3.1.7 to 3.2.0
Thanks Justin. I am embedding Perl inside a C program, so I hope this is
still true. It used to return a non-NULL or at least the following call
used to always return a "count" of 1 and not 0 like it is now after the
SA upgrade.
count = perl_call_method("Mail::SpamAssassin::PerMsgStatus::finish",
(G_ARRAY|G_EVAL|G_KEEPERR));
Is your answer still the same?
Thanks a lot!
Joe
Justin Mason wrote:
hi Joe --
just ignore the return value of finish() -- it's a void method.
(note how it doesn't mention a return value in its POD doc ;)
--j.
Joe Flowers writes:
Hello Everyone,
I'm getting a weird error message that I have never gotten before over
several versions of SA. I just upgraded from "SpamAssassin version 3.1.7
running on Perl version 5.8.8" to "SpamAssassin version 3.2.0 running on
Perl version 5.8.8". Now, my calls to
Mail::SpamAssassin::PerMsgStatus::finish are "failing"; or at least, it
looks like their has been some change in the return values by finish().
I have been running this programming over many iterations of SA and this
is the first time I have run into such a problem.
This worries me a lot because from the docs
(http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_PerMsgStatus.html):
"
$status->finish ()
If you are using SpamAssassin in a persistent environment, or
checking many mail messages from one Mail::SpamAssassin factory, this
method should be called to ensure Perl's garbage collection will clean
up old status objects.
".
These calls "succeed" as usual:
Mail::SpamAssassin::PerMsgStatus::get_required_score
Mail::SpamAssassin::PerMsgStatus::get_score
Mail::SpamAssassin::PerMsgStatus::is_spam
Mail::SpamAssassin::PerMsgStatus::get_names_of_tests_hit
"succeeded".>
Any ideas please?
Joe
Re: Mail::SpamAssassin::PerMsgStatus::finish "failing" after upgrade from 3.1.7 to 3.2.0
hi Joe -- just ignore the return value of finish() -- it's a void method. (note how it doesn't mention a return value in its POD doc ;) --j. Joe Flowers writes: > Hello Everyone, > > I'm getting a weird error message that I have never gotten before over > several versions of SA. I just upgraded from "SpamAssassin version 3.1.7 > running on Perl version 5.8.8" to "SpamAssassin version 3.2.0 running on > Perl version 5.8.8". Now, my calls to > Mail::SpamAssassin::PerMsgStatus::finish are "failing"; or at least, it > looks like their has been some change in the return values by finish(). > > I have been running this programming over many iterations of SA and this > is the first time I have run into such a problem. > > This worries me a lot because from the docs > (http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_PerMsgStatus.html): > " > $status->finish () > > If you are using SpamAssassin in a persistent environment, or > checking many mail messages from one Mail::SpamAssassin factory, this > method should be called to ensure Perl's garbage collection will clean > up old status objects. > ". > > These calls "succeed" as usual: > > Mail::SpamAssassin::PerMsgStatus::get_required_score > Mail::SpamAssassin::PerMsgStatus::get_score > Mail::SpamAssassin::PerMsgStatus::is_spam > Mail::SpamAssassin::PerMsgStatus::get_names_of_tests_hit > "succeeded".> > > Any ideas please? > > Joe
Bayes combining and OCR (Was Re: SpamAssassin 3.2 compatiblity)
Matthias Keller writes: > Nix wrote: > > On 31 May 2007, Graham Murray said: > > > > > >> Nix <[EMAIL PROTECTED]> writes: > >> > >> > >>> (And, let's be blunt, the pure this-word-is-spammy recognition part of > >>> FuzzyOCR is much less smart than the Bayesian system already present > >>> in SA: FuzzyOCR should really use the Bayesian system to determine the > >>> spamminess of words, I suppose...) > >>> > >> Or even just act as a MIME part 'decoding' system (like Base64) and feed > >> all words it finds in images into Bayes, along with all other text in > >> the mail, rather than generating a score itself. > >> > > > > Perhaps so, but if so those words should have a score-multiplier of some > > sort applied, because the fact that those words originated in images is > > itself an obfuscation technique that should be noted in the score. > > > This has been discussed here again and again and again > > first of all, these 10 words found in an image cannot stand against the > bayes poisoning found in all these messages - so it would literally be > useless for bayes filtering by the way, this is a common misconception of how our Bayes system works; what *should* happen is that the "poison" text winds up with "weak" Bayesian probability scores between 0.2 and 0.8, since it uses words that also appear in ham (hence why it appears as poison). However, the OCR'd text would wind up with "strong" scores around 0.99 or greater. The chi-square probability combining algorithm we use takes care of this, by discounting the "weak" clues and taking more account of the "strong" clues. (This is what makes it a more effective combining algorithm for Bayes than the traditional Graham style.) Note: this relies on the use of a different "namespace" for OCR-discovered words, btw; ie. if the words "make money fast" are found in OCR'd text, it'd generate "OCR:make", "OCR:money", "OCR:fast". If the OCR-discovered words are just thrown in with normal text words, that wouldn't work. --j.
Re: How To Kill Spam Dead?
Matt Kettler writes: > [lots of correct stuff] > ... > Anyone telling you spammers only or mostly use bogus return addresses > either hasn't studied spam extensively or is deluding themselves. Well, they *used* to use bogus addresses -- that was the case 2 or 3 years ago, before Sender Address Verification [1]. Since then, spam generally uses randomly-chosen, "real" user addresses, as Matt says. [1]: http://taint.org/2007/03/16/134743a.html I've written my thoughts about C-R backscatter here: [2] [2]: http://taint.org/2005/09/11/012434a.html The only way I can see to have a NON-abusive challenge-response system nowadays, would be to restrict challenges to domains for which the challenged message passed SPF, Domain Keys or DKIM tests. (You'd still annoy your correspondents, but at least you wouldn't be creating spam for innocent third parties.) None of the C-R filters bother doing that, though. --j.
Mail::SpamAssassin::PerMsgStatus::finish "failing" after upgrade from 3.1.7 to 3.2.0
Hello Everyone, I'm getting a weird error message that I have never gotten before over several versions of SA. I just upgraded from "SpamAssassin version 3.1.7 running on Perl version 5.8.8" to "SpamAssassin version 3.2.0 running on Perl version 5.8.8". Now, my calls to Mail::SpamAssassin::PerMsgStatus::finish are "failing"; or at least, it looks like their has been some change in the return values by finish(). I have been running this programming over many iterations of SA and this is the first time I have run into such a problem. This worries me a lot because from the docs (http://spamassassin.apache.org/full/3.2.x/doc/Mail_SpamAssassin_PerMsgStatus.html): " $status->finish () If you are using SpamAssassin in a persistent environment, or checking many mail messages from one Mail::SpamAssassin factory, this method should be called to ensure Perl's garbage collection will clean up old status objects. ". These calls "succeed" as usual: Mail::SpamAssassin::PerMsgStatus::get_required_score Mail::SpamAssassin::PerMsgStatus::get_score Mail::SpamAssassin::PerMsgStatus::is_spam Mail::SpamAssassin::PerMsgStatus::get_names_of_tests_hit "succeeded".> Any ideas please? Joe
Re: SpamAssassin 3.2 compatiblity
Nix wrote: On 31 May 2007, Graham Murray said: Nix <[EMAIL PROTECTED]> writes: (And, let's be blunt, the pure this-word-is-spammy recognition part of FuzzyOCR is much less smart than the Bayesian system already present in SA: FuzzyOCR should really use the Bayesian system to determine the spamminess of words, I suppose...) Or even just act as a MIME part 'decoding' system (like Base64) and feed all words it finds in images into Bayes, along with all other text in the mail, rather than generating a score itself. Perhaps so, but if so those words should have a score-multiplier of some sort applied, because the fact that those words originated in images is itself an obfuscation technique that should be noted in the score. This has been discussed here again and again and again first of all, these 10 words found in an image cannot stand against the bayes poisoning found in all these messages - so it would literally be useless for bayes filtering secondly, the hit rate of the OCR is pretty bad, so we cannot use exact matches - that's exactly why this app is named FUZZYocr, compared to the original version which wasn't fuzzy - that's why we have such high hit rates with it because it can still find these words even if one or two letters are wrong - try to do that with regular expressions and it gets ugly and big quite fast FuzzyOCR is perfect just the way it is. It might need some tweaking, yes, but then it can do exactly what you want. If you want an upper limit, just hack the source and add it - it's not too hard. I've added a few tweaks myself - for example dont stop if the minimum words was found with one scanset but continue unil the minimum+10 have been found.. I dont want it to stop at 2 words if a later scanset could find 15 I agree, an upper bound would be quite interesting for a few folks (actually I dont mind having a fuzzyocr hit with 20+ hits, that's just perfect actually because the FP rate was zero so far) and it shouldn't be too hard to add - so you might officially request this for a next version or like I said - just do it yourself. If you cant do it, I might have a look and give you a hint into the right direction, even tough I'm not really a good perl programmer Matt
Re: How to avoid filtering twice when having mail-groups
Manu schrieb: Hi all, I'm using SpamAssassin 3.0.2 and Qmail on a Debian Sarge Server. Administrative hosting panel is Plesk 8.1. Imagine the following situation: [EMAIL PROTECTED] forwards to [EMAIL PROTECTED], [EMAIL PROTECTED],... Now if SpamAssassin checks [EMAIL PROTECTED] and each user has enabled spam filtering too, SpamAssassin will filter the same message once for mailgroup@ and then once again for each user. We'll get: 1 + #users scans. If I disable scanning of mailgroup@, we'll get #user scans for the very same message. What I would like to have: SpamAssassin scans for mailgroup@ and when the very same message has to be scanned for each user, SpamAssassin remembers that this message has already been scanned seconds ago and doesn't scan it again. SpamAssassin sometimes needs 15 seconds to process a message, so you can imagine that this will save much time and ressources for mailgroups with many recipients. Any chance to get this working? I cant imagine this could be done. Cause SA gets every "single recipient" from MTA, if possible i think you would have to put another filter/script in the chain to pass only 1 address if certain circumstances (aliases for a address are there). But perhaps a more experienced user here, might know more ... Thanks in advance. -- Grüsse/Greetings MH Dont send mail to: [EMAIL PROTECTED] --
Re: +36% incomining spam
Giampaolo Tomassoni schrieb:
With respect to the previous Monday.
Just wondering why. Are they close to vacation and need to rise some money
to bring their children in vacation?
Here i can always watch an increase through holidays,
seems the botnets get new "feed" when kids power up their virus
contaminated (Windows) boxes ...
Also some new spambot-owners might be more aggressive around ...
Around the weekend of Whitsun ("Pfingsten" in ger) it was really bad
here ...
Anybody knows which is the pattern behind this things?
Regards,
Giampaolo
--
Grüsse/Greetings
MH
Dont send mail to: [EMAIL PROTECTED]
--
Re: create script sa-learn
On 14-May-2007, at 05:46, Bruno Henrique de Oliveira wrote:
Necessary of aid to create one script that it reads the
folder .Trainings inside of the Maildir of the user and train as Spam.
Soon after the trainings the same script has that to move this message
for the Inbox of a called user Spam. One of the problems and use of
the
vpopmail, the users of the same are not recorded in the /etc/shadow
archive. Suggestions of as to mount this script are comings well.
This is what I use:
#/bin/sh
#
# Straightforward shell script to be run as root. This parses the /home
# directory for mailboxes named sa-learn-sapm and sa-learn-ham and runs
# sa-learn against them as the user.
# sa-learn-script (sal) v1.0 Lewis Butler, released to the Public
Domain 2007
#
# $PREFIX is the prefix for the mailbox name, the two SUFFIX variable
for
# each type of mail, and the MAILP for the path from $HOME to the mboxes
# to learn, the default is:
#
# /home//Mail/sa-learn-ham
# /home//Mail/sa-learn-spam
PREFIX="sa-learn-";
SPAMSUFFIX="spam";
HAMSUFFIX="ham";
USERROOT="/home";
MAILP="Mail/$PREFIX";
MYDATE=`date '+%d-%b-%Y'`;
#echo "$MYDATE";
for i in `ls $USERROOT/` ; do
S_PATH="$USERROOT/$i/${MAILP}$SPAMSUFFIX";
H_PATH="$USERROOT/$i/${MAILP}$HAMSUFFIX";
#echo "";
#echo "Checking user: $i";
# Don't run sa-learn if there is no such mbox, or if the mbox is empty
if test -s $S_PATH; then
# echo -n "$i Processing Spam: ";
/usr/local/bin/sa-learn --spam --mbox -u $i $S_PATH
/usr/local/bin/sudo -u $i sh -c "cat $S_PATH >> ${S_PATH}-$MYDATE
&& \
cat /dev/null > $S_PATH";
fi
# Don't run sa-learn if there is no such mbox, or if the mbox is empty
if test -s $H_PATH; then
# echo -n "$i Processing Ham : ";
/usr/local/bin/sa-learn --ham --mbox -u $i $H_PATH
/usr/local/bin/sudo -u $i sh -c "cat $H_PATH >> ${H_PATH}-$MYDATE
&& \
cat /dev/null > $H_PATH";
fi
#echo "$i DONE";
done
This, however, works just as well for most purposes and is much much
shorter (in fact, it works well as a one liner).
for i in `ls /home/`;
do find /home/$i/Mail/sa-learn-spam | sa-learn --spam --mbox -u $i;
sa-learn --ham --mbox -u $i /home/$i/Mail/sa-learn-ham;
echo "$i DONE";
done
Vpopmail
Ah... er... well, not familiar with vpopmail...
--
Rumour is information distilled so finely that it can filter through
anything. It does not need doors and windows -- sometimes it does not
need people. It can exist free and wild, running from ear to ear
without ever touching lips.
Re: How To Kill Spam Dead?
Dennis Kavadas wrote: > why isn't it useful in a business context ? > there sender gets a challange once ! ...how is that a problem ? > Hi Dennis, It's not a problem per se, just not very useful. In a business context, in particular in a non-English speaking country, the challenge will often cause confusion. Perhaps not for techies, but e.g. for secretaries, and other non-IT functions. And most businesses have more of those than techies. So a TMDA challenge is often at first a time-waster, and later just ignored. /Per Jessen, Zürich
Re: OBSCURED_EMAIL ?
Daryl C. W. O'Shea wrote: > Yeah, I could. I'd rather just point you at the text you quoted above > (^ really is substituted for @) or the email Theo sent earlier > suggesting the same thing. Combine that with rot13, or any other > rotNN you prefer. Last comment from my side - what I'm having a bit of an issue with is this seemingly arbitrary substitution of '^' for '@', and that the rule that is desribed as "Message seems to contain rot13ed address" expects this, but couldn't actually catch anything that _was_ rot13'ed. The only other rotNN I know of is rot47, and that doesn't turn an '@' into a '^' either. > Yes, in your particular case it wasn't your email addressed obscured, > it was a hit on a binary part. Very true - for me, the focus has already shifted to the issue of embedded uuencoded files, which I think is more critical. > Sometimes rules hit things they're not intended to, or things they are > intended to hit but in ham. That's why SA is a score based system. > If you find that this particular rule is causing you problems perhaps > you may want to consider assigning it a zero score. Certainly. I was merely trying to bring it others' attention that this rule in my opinion has a much too high default score, and it does more bad than good. /Per Jessen, Zürich
Re: SpamAssassin 3.2 compatiblity
On 31 May 2007, Graham Murray said: > Nix <[EMAIL PROTECTED]> writes: > >> (And, let's be blunt, the pure this-word-is-spammy recognition part of >> FuzzyOCR is much less smart than the Bayesian system already present >> in SA: FuzzyOCR should really use the Bayesian system to determine the >> spamminess of words, I suppose...) > > Or even just act as a MIME part 'decoding' system (like Base64) and feed > all words it finds in images into Bayes, along with all other text in > the mail, rather than generating a score itself. Perhaps so, but if so those words should have a score-multiplier of some sort applied, because the fact that those words originated in images is itself an obfuscation technique that should be noted in the score. -- `On a scale of one to ten of usefulness, BBC BASIC was several points ahead of the competition, scoring a relatively respectable zero.' --- Peter Corlett
Installing 3.20 in FreeBSD
OK, so I downloaded the test sa320.tgz file and followed the instructions and when I go to make I get: NOTE: the optional libnet module is not installed. Trouble is, libnet11-1.1.2.1_1,1 is installed. I even deleted it and reinstalled it. I also get: NOTE: the optional Compress::Zlib module is installed, but is not an up-to-date version. but according to ports, p5-Compress-Zlib-2.004 is current OK, so it's running, and libnet is not a big deal as I don't use spamcop, but it seems weird to me. -- Yeah, Nick. Nick's the kinda guy you can trust. Nick's your buddy. Nick's the kinda guy you drink beers with. The kinda guy that doesn't care if you puke in his car. Nick.
Re: VBounce not working in 3.2.0
On Wednesday 30 May 2007 21:36, Justin Mason wrote: > Guys -- could you open a bugzilla entry about this, attaching > (a) sample messages that are missed and (b) your relevant configuration > lines? it sounds like it may have something to do with how the > bounces are formatted, I'd guess. Done, #5492 Bob
