Re: interesting paper on SoBig's authorship
http://authortravis.tripod.com/ http://www.geocities.com/author_travis/ very interesting! --j. One of the things mentioned in the article is that Spam Sent using Send-Safe/Sobig as well as being delivered directly (using fake return addresses etc) is *ALSO* sent deliberately to addresses where it will bounce, with the actual intended recipient as the Return address - thus the victim gets a bounce message with the spam attached, which usually eludes spam filtering tools like Spamassassin. (Since the bounce isn't actually spam, only the attachment within it) This is a technique I've been aware of for a long time now, and have brought the issue up in the past a couple of times, but are there any plans to combat this in future versions of SpamAssassin ? In recent times I'm seeing far more spam bounces, than normal spam escaping spamassasin. (EG although spam bounces probably account for a small percentage of spam at the moment, I find nearly all of them get past spamassassin, and I think the percentage will increase) As far as I can see it would basically mean scanning a message twice in some cases, and the most efficient way to do it would be in SpamAssassin itself, rather than hacking together external tools to extract the attachment and two messages to SpamAssasin. - 1st pass - scan as per normal. - If the message is found to be spam using normal techniques, don't do anything futher (eg, we got it, don't waste any more processing time) - If the message is not spam, but it has what looks like an RFC822 attachment, (found in bounce messages) rescan the attachment as if it were a message in its own right, (eg header rules apply to headers in the attachment etc) and if THAT attachment is found to be spam, then we flag it as spam with the score obtained within the attachment. - If the attachment is clean, flag the message as ham, using the score found in the containing (outside) message body. Scanning attachments could be an optional .cf controlled feature. The advantage I see is that in the vast majority of cases, the message is still only scanned once, so the actual overhead is very low: 1) Ham doesn't often have attached emails, a few people like to forward messages that way, but thankfully they're in the minority. ;-) So for the majority of ham the code would just see there are no RFC822 attachments so do nothing extra. 2) Normal spam will already be detected as spam anyway, so whether it has a spammy attachment on top of that is irrelevant. Case 1 and 2 account for the vast majority of messages. As far as I can see there are only two obsticles - reliably detecting the presense of an RFC822 style message bounce attachment and extracting it for processing, (and being able to handle the case of nesting of attached messages, or multiple attachments per message in a sensible way) and coding in a bit of simple logic to decide whether to scan attachments. Regards, Simon
Re: since 3.0.0 I've been getting these
Theo Van Dinter wrote:
On Mon, Nov 01, 2004 at 05:17:34PM -0600, Tim Litwiller wrote:
Nov 1 17:38:42 mailhost spamd[15700]: Use of uninitialized value in
numeric lt () at
/usr/lib/perl5/site_perl/5.6.1/Mail/SpamAssassin/Plugin/SPF.pm line 204,
GEN362 line 52.
Nov 1 17:38:42 mailhost spamd[15700]: Use of uninitialized value in
concatenation (.) or string at
/usr/lib/perl5/site_perl/5.6.1/Mail/SpamAssassin/Plugin/SPF.pm line 205,
GEN362 line 52.
which is
$self-register_eval_rule (check_for_spf_helo_softfail);
You don't want line 52, you want lines 204 and 205:
if ($Mail::SPF::Query::VERSION 1.996) {
die Mail::SPF::Query 1.996 or later required, this is
$Mail::SPF::Query::VERSION\n;
What version of Mail::SPF::Query do you have installed? My guess is
something 1.996.
I really have no idea as it wasn't something I installed seperately ...
I just checked and it is 1.997
Re: since 3.0.0 I've been getting these
On Mon, Nov 01, 2004 at 11:04:39PM -0600, Tim Litwiller wrote: I really have no idea as it wasn't something I installed seperately ... I just checked and it is 1.997 1.997 works fine (it's what I have installed on my box), are you sure you don't have an old version hanging out somewhere? Just to verify: perl -e 'use Mail::SPF::Query; print $Mail::SPF::Query::VERSION,\n' -- Randomly Generated Tagline: Dijkstra probably hates me (Linus Torvalds, in kernel/sched.c) pgpR6e70JDTKu.pgp Description: PGP signature
Linux and pop3 proxy
Hi, Sincere apologies if this question has been answered elsewhere but I have not been able to find a succinct solution. Currently I'm using SA in a small office. It is an earlier version running on Windows and using pop3proxy mcd.perlmonk.org/pop3proxy/ the set-up seems unstable, as emails are sometimes not received until a reboot of the machine is performed. A mail server run off site by our local ISP collects all our emails. We have a Linux box that I would like to use for the SA service and perhaps upgrade to the latest version and include some more in-depth tests like DNS. I need to keep the proxy as retrieving the emails to the local machine (with fetchmail) and then collecting the emails (by running postfix) locally will cause all sorts of political problems. I have investigated p3scan but dont want all users to run through SA just two users in our network. Again this is political. It is my understanding of p3scan that it is an all or nothing system. I am inexperienced with iptables and dont know if this could be a solution. I.e. routing requests to mail.isp.com 110 from local machine 192.168.x.y to the machine running p3scan. Upon rereading this it should be possible but I am not sure. I could continue to use pop3proxy on the Linux machine (it may be more stable) but since it is targeted towards Windows I thought there must be a better solution. So, is there a pop3 proxy solution for Linux to run SA for a few client machines or should I just use the pop3proxy perl script on the Linux machine and see how it goes? Thanks for any advice. Daniel.
Re: trusted_networks and ALL_TRUSTED
On Mon, 2004-11-01 at 18:24, Matt Kettler wrote: At 01:07 PM 11/1/2004, Sean Doherty wrote: so the *next* step must be the external MX. My 10.x server is inside a firewall which NATs port 25 so this conclusion is not correct. I imagine that my setup isn't all that different from a lot of other peoples. Yes, it is incorrect, but SA can't know that. Thus, SA assumes, incorrectly, that any 10.x host must not be externally addressable. It's not a very good assumption in modern networks, but there's not much else one can do. SA's trust path code has pretty much always been incompatible with NAT'ed mailservers. And it's hard for SA to autodetect such things from mail headers. Obviously, there's no way to deduce that the mail path has come through a NAT'ed firewall, and as such in certain situations guessing the trusted_networks is not the correct thing to do. I have always (incorrectly) been running SpamAssassin without trusted_networks been set, which when running SA 2.64 resulted in no DNSBL checks. Because I was running Bayes, SURBLs and a bunch of custom rules I wasn't seeing FPs. However, after upgrading to 3.0 I suddenly started seeing much more FPs, which I could be attributed to ALL_TRUSTED. Setting trusted_networks appropriately has solved the problem, however, given that the inference algorithm doesn't deal well with NAT'ed networks - which IMO is quite common for SMEs - there should be perhaps something in the debug output which informs the user that trusted_networks is not set and as such will be guessed. Another option would be to either trust nobody, or not run those tests that rely on knowing what the trusted networks are. Regards, - Sean
Re: Per-user capabilities
From: Khalid Waheed [EMAIL PROTECTED]
SpamAssassin has all sorts of per-user capabilities, including whitelists,
rule weights, and Bayesian filtering.
But all of this stuff is totally useless in some mail servers (e.g. SunOne
messaging server), for the simple reason that being able to process mail for
multiple users simultaneously is an absolutely critical capability, and
SpamAssassin is simply not designed to offer this capability.
Sh, please, not so loud. My system might hear you and get funny ideas.
{o.o}
Re: Automatic rejection
On Tuesday 02 November 2004 12:33, Moussa Fall might have typed: Question from a newbie: can anyone point me to a location where I can find out to make spamassassin automatically reject spam? I noticed that all tagged spam are really spams and I do not want users to receive mail with scores, etc. SpamAssassin does not do any kind of rejections, it is a 'mere' classifier. You will need another tool in the pipeline that can work out what the score was, and act on the score.
?
I love spamassasin, but I hate this: X-Spam-Status: SpamAssassin Failed I look to the log file, to the debug, soo at all, but I can`t find anything? What can give this error? -- Orlov Alex, Head of IT, IPB Russia [EMAIL PROTECTED] Work phone (10am-7pm): +7-095-9757228 GSM phone (24h): +7-916-6147263
Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED
On Tue, Nov 02, 2004 at 10:24:57AM +, Sean Doherty wrote: On Mon, 2004-11-01 at 20:37, George Georgalis wrote: skip_rbl_checks 1 use_bayes 0 noautolearn 1 use_auto_whitelist 0 score AWL 0.001 trusted_networks 192.168. score ALL_TRUSTED 0.001 Do you mean -0.001? Why would you want to penalise mail coming thru a trusted path? It really doesn't matter to me what the score is, I just want to disable the test. http://bugzilla.spamassassin.org/show_bug.cgi?id=3406 My /etc/spamassassin is the reference I replicate out to my other systems, and systems of my clients, which may or may not be on nat and certainly are on different networks. The setup I use routes mail at the tcp level, it's basically impossible for a message to reach spam assassin if it's from a trusted network. I had scored ALL_TRUSTED to 0 but then decided I needed to know in test reports what was happening. I don't know how much cpu this test uses, but I'd like it to go away completely, or at have the option of disabling it. // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED
On Tue, 2004-11-02 at 12:50, George Georgalis wrote: Do you mean -0.001? Why would you want to penalise mail coming thru a trusted path? It really doesn't matter to me what the score is, I just want to disable the test. http://bugzilla.spamassassin.org/show_bug.cgi?id=3406 My /etc/spamassassin is the reference I replicate out to my other systems, and systems of my clients, which may or may not be on nat and certainly are on different networks. The setup I use routes mail at the tcp level, it's basically impossible for a message to reach spam assassin if it's from a trusted network. So why not set trusted_networks to 127.0.0.1. That way you can be certain that the rule will never fire. You'll also get the benefit of the DNS blocklists been checked for the addresses in the Received headers - with your current setup, its possible that some of these will be marked as trusted, and as such you'll lose the benefit of the RBL check. I had scored ALL_TRUSTED to 0 but then decided I needed to know in test reports what was happening. I don't know how much cpu this test uses, but I'd like it to go away completely, or at have the option of disabling it. // George
Re: Automatic rejection
Thank you, Martin and Duncan! Sorry I did not mention this information. I am using RH9 with Postfix. Maybe I can use Mailscanner. On 2 Nov 2004 at 12:53, Martin Hepworth wrote: Moussa Fall wrote: Question from a newbie: can anyone point me to a location where I can find out to make spamassassin automatically reject spam? I noticed that all tagged spam are really spams and I do not want users to receive mail with scores, etc. Thank you. Hi if you want to 'reject' the email you'll need to use milter with sendmail or something similir for your MTA (exim, postfix..) If you want to accept all email then process before delivery you can use MailScanner or amavis-new - I use MailScanner. or you could use procmail if you are on a *nix ermail server to process the emails upon deliver. -- Martin Hepworth Senior Systems Administrator Solid State Logic Ltd tel: +44 (0)1865 842300 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote confirms that this email message has been swept for the presence of computer viruses and is believed to be clean. **
Re: Automatic rejection
On Tuesday 02 November 2004 13:24, Moussa Fall might have typed: Thank you, Martin and Duncan! Sorry I did not mention this information. I am using RH9 with Postfix. Maybe I can use Mailscanner. The folks on the postfix list will thwack you if you use mailscanner, as it apparently uses unsupported methods to muck directly with the postfix queue. I have a preference for amavisd-new running as a postfix content filter. This applies the scanning at the SMTP stage, after postfix has validated that the recipient is valid. Alternately, you can fit spamassassin into the delivery pipeline (procmail, maildrop) and have per-user bayes etc.
Re: ?
At 03:45 PM 11/2/2004 +0300, Alexandr Orlov wrote: I love spamassasin, but I hate this: X-Spam-Status: SpamAssassin Failed I look to the log file, to the debug, soo at all, but I can`t find anything? What can give this error? Don't know...AFAIK spamassassin itself will never generate this... Are you using an integration tool like amavis or something similar which might be generating the message?
Re: Automatic rejection
Duncan Hill wrote: On Tuesday 02 November 2004 13:24, Moussa Fall might have typed: Thank you, Martin and Duncan! Sorry I did not mention this information. I am using RH9 with Postfix. Maybe I can use Mailscanner. The folks on the postfix list will thwack you if you use mailscanner, as it apparently uses unsupported methods to muck directly with the postfix queue. I have a preference for amavisd-new running as a postfix content filter. This applies the scanning at the SMTP stage, after postfix has validated that the recipient is valid. Alternately, you can fit spamassassin into the delivery pipeline (procmail, maildrop) and have per-user bayes etc. There is little love lost between the two main developers of Postfix and MailScanner, and I don't think there's little hope of any resolution on this in the sort term (postfix developer objects to messages being moved from queue to another ny a third party piece of software, and the MailScanner doesn't see any need to recode the whole dataflow of MailScanner for one MTA when 'it works anyway'). Lots of people use the two together and it works fine. -- Martin Hepworth Senior Systems Administrator Solid State Logic Ltd tel: +44 (0)1865 842300 ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote confirms that this email message has been swept for the presence of computer viruses and is believed to be clean. **
Re: Automatic rejection
At 01:24 PM 11/2/2004 +, Moussa Fall wrote: Thank you, Martin and Duncan! Sorry I did not mention this information. I am using RH9 with Postfix. Maybe I can use Mailscanner. Regardless of objections to using MailScanner with postfix (not supported by the postfix guys, but does seem to work for a lot of people) Don't *ever* use mailscanner's bounce feature.. It's broken beyond belief and makes your server into a DDoS tool. (Expands the scope of a Joe-job from a single-source DoS to a multi-source DDoS) Many in the community, myself included, asked Julian to remove this feature, but at least one large site admin with a I don't care who's site I DDoS, I want to bounce them because this makes mail 'reliable'... attitude insisted he leave it in. So Julian deferred to adding a few extra hoops to enable the feature. I myself have a standing policy of blacklisting with a 550 nastygram any server generating more than two such messages in a 24 hour period as a defensive measure. If you want to reject mail in a less-damaging way, you need a MTA layer integration that gets called directly from the MTA's pipeline before the mail is accepted. Since you're using postfix, your simplest way, as Duncan suggested, is amavis. You can also make SA a content filter directly in postfix's master.cf. I'm not sure how this works, but I suspect this will allow direct rejection. http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix
Re[2]: interesting paper on SoBig's authorship
Hello Simon, Monday, November 1, 2004, 6:04:53 PM, you wrote: SB One of the things mentioned in the article is that Spam ... SB is *ALSO* sent deliberately to addresses where it will SB bounce, with the actual intended recipient as the Return address SB ...\ SB This is a technique I've been aware of for a long time now, and have SB brought the issue up in the past a couple of times, but are there any SB plan to combat this in future versions of SpamAssassin ? I've been quite happy with http://www.timj.co.uk/linux/bogus-virus-warnings.cf from Tim Jackson. His scoring has been a bit more aggressive than I like, but his rules work well for rejecting spam and virus bounces. Bob Menschel
Site-wide bayes database, autolearn address
Hi, Just upgraded to 3.0.1 running under qmail on OpenBSD and am happy to report no problems. However, whilst I was doing this, I had a few ideas. I've had a shufty through the archives for these but I didn't find an appropriate answer. I have 3 questions: 1. I would like to setup a sitewide bayes database that all mailboxes will use. This saves having to make every user learn their own spam and should improve the overall accuracy of the system. Is this particularly difficult to setup with an SQL backend? What happens if the database is unavailable? What is the performance hit on the database in these situations? We see around 2 messages a day on the server. 2. I would like to setup an automatic email address that people can send uncaught spam to, which will then be learnt as spam and put into the bayes database. Has anyone managed to do this? The problem I forsee is handling the forward as attachment or forward inline that different mail clients use. Presumably we would need to make people forward them as attachments, then have a procmail script that handles all mail accordingly. 3. I see entries such as: autolearn=ham autolearn=spam autolearn=unavailable autolearn=none In the mail logs. Is there a spam score threshold that triggers the autolearning behaviour? Is the default sensible? Should it be a little lower? I see high-scored spam not being learned as such and wonder if this ought to be tweaked a little. Gaby -- Ha! Ha! Ha! Dislocation... - Phil Ken Sebben [EMAIL PROTECTED] http://vanhegan.net
Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED
On Tue, Nov 02, 2004 at 01:03:02PM +, Sean Doherty wrote: On Tue, 2004-11-02 at 12:50, George Georgalis wrote: Do you mean -0.001? Why would you want to penalise mail coming thru a trusted path? It really doesn't matter to me what the score is, I just want to disable the test. http://bugzilla.spamassassin.org/show_bug.cgi?id=3406 My /etc/spamassassin is the reference I replicate out to my other systems, and systems of my clients, which may or may not be on nat and certainly are on different networks. The setup I use routes mail at the tcp level, it's basically impossible for a message to reach spam assassin if it's from a trusted network. So why not set trusted_networks to 127.0.0.1. That way you can be certain that the rule will never fire. You'll also get the benefit of the DNS blocklists been checked for the addresses in the Received headers - with your current setup, its possible that some of these will be marked as trusted, and as such you'll lose the benefit of the RBL check. There is lots of reasons not to do something. What I'm not seeing is a reason why I can't stop trusted_networks from using cpu/dns. your idea sounds okay for some applications (and I'm changing from 192.168 to 127.0.0.1 as a matter of course), but I don't want every address in headers looked up. I don't want any of them looked up. I hope it's okay for me to be that way. I am concerned about the IP a message is coming from, but in my setup, that is dealt with before SA ever sees the message. // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
Re: Error after upgrading to 3.0.1
After upgrading from 3.0.0 to the latest version I get the following error:- ERROR! spamassassin script is v3.00, but using modules v3.01! Any idea what scrip its refering to, spamassassin --lint -D worked just fine, but cant fire up spamd. Martin I had the same problem - copy the files from /opt/local/scripts to /opt/local/bin Keith
SA via CGPAV
I'm calling SA via cgpav. Seems that cgpav does its own interpretation of the results from spamd. The report is no longer attached, for one. Is there anyone out there who has fiddled with the cgpav source? I'd like to get back to the way that things were under spamass-milter. Thanks! Scott
Re: Site-wide bayes database, autolearn address
Hi, Just upgraded to 3.0.1 running under qmail on OpenBSD and am happy to report no problems. However, whilst I was doing this, I had a few ideas. I've had a shufty through the archives for these but I didn't find an appropriate answer. I have 3 questions: 1. I would like to setup a sitewide bayes database that all mailboxes will use. This saves having to make every user learn their own spam and should improve the overall accuracy of the system. Is this particularly difficult to setup with an SQL backend? What happens if the database is unavailable? What is the performance hit on the database in these situations? We see around 2 messages a day on the server. 2. I would like to setup an automatic email address that people can send uncaught spam to, which will then be learnt as spam and put into the bayes database. Has anyone managed to do this? The problem I forsee is handling the forward as attachment or forward inline that different mail clients use. Presumably we would need to make people forward them as attachments, then have a procmail script that handles all mail accordingly. 3. I see entries such as: autolearn=ham autolearn=spam autolearn=unavailable autolearn=none In the mail logs. Is there a spam score threshold that triggers the autolearning behaviour? Is the default sensible? Should it be a little lower? I see high-scored spam not being learned as such and wonder if this ought to be tweaked a little. Gaby -- Ha! Ha! Ha! Dislocation... - Phil Ken Sebben [EMAIL PROTECTED] http://vanhegan.net As for 1 and 3, I don't know, but 2, I did myself. Actually, the biggest problem you'll run into is that when you forward the message, it tinkers with the headers of the message. I found a solution to this that doesn't require special scripts to strip the 'false' headers. We run SquirrelMail as a webmail front-end to courier-imap. I created a couple buttons as an extension to the amavis-sa plugins in SquirrelMail. The buttons are this is spam and this isn't spam. When a user clicks one of these, it actually moves the message (yes, at the OS level) from the mbox of the user who is viewing their email to my spam only mailbox. Fortunately, courier is pretty tolerant to this type of abuse. Keith
Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED
On Tue, Nov 02, 2004 at 03:40:02PM +, Sean Doherty wrote: On Tue, 2004-11-02 at 15:16, George Georgalis wrote: The setup I use routes mail at the tcp level, it's basically impossible for a message to reach spam assassin if it's from a trusted network. So why not set trusted_networks to 127.0.0.1. That way you can be certain that the rule will never fire. You'll also get the benefit of the DNS blocklists been checked for the addresses in the Received headers - with your current setup, its possible that some of these will be marked as trusted, and as such you'll lose the benefit of the RBL check. There is lots of reasons not to do something. What I'm not seeing is a reason why I can't stop trusted_networks from using cpu/dns. your idea sounds okay for some applications (and I'm changing from 192.168 to 127.0.0.1 as a matter of course), but I don't want every address in headers looked up. I don't want any of them looked up. I hope it's okay for me to be that way. I am concerned about the IP a message is coming from, but in my setup, that is dealt with before SA ever sees the message. You can stop dns lookups by setting dns_available no which results in the following if trusted_networks is unset. debug: received-header: cannot use DNS, do not trust any hosts from here on However, this also disables SURBLs - which you probably still want! I don't think its possible to disable DNS lookups for trusted networks without also disabling it for the SURBLs. Thanks, indeed I do use SURBLs. and am quite pleased with those! // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
RE: Error after upgrading to 3.0.1
|-Original Message- |From: Keith Hackworth [mailto:[EMAIL PROTECTED] |Sent: 02 November 2004 15:40 |To: marti |Cc: Spamassassin |Subject: Re: Error after upgrading to 3.0.1 | | After upgrading from 3.0.0 to the latest version I get the following | error:- | | ERROR! spamassassin script is v3.00, but using modules |v3.01! | | Any idea what scrip its refering to, spamassassin --lint -D worked | just fine, but cant fire up spamd. | | Martin | | | |I had the same problem - copy the files from |/opt/local/scripts to /opt/local/bin | |Keith | I don't have such a directory, it installs to /usr/lib/perl5/site_perl/5.8.0/Mail /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin /usr/bin/spamc /usr/bin/spamd /etc/mail/spamassassin Using locate I can confirm there are no other directories other than a backup directory I put all the rules in, so can only think that it dosent like one of the scripts that came in the Mail-SpamAssassin-3.0.1.tar.gz. What do you class as a script, is that a .cf? or could that be any file in the package? Is there anyway to get a debug output from spamd so I can see which script its borking on? I have run out of ideas now as to whats causing this, is there a bug in make install, this should just be a simple process, this is ridiculous. Martin
Re: Site-wide bayes database, autolearn address
Keith Hackworth wrote: As for 1 and 3, I don't know, but 2, I did myself. Actually, the biggest problem you'll run into is that when you forward the message, it tinkers with the headers of the message. I found a solution to this that doesn't require special scripts to strip the 'false' headers. Forwarding the email as an attachment may help, but as you say, it will rip out most of the headers. We do have SquirrelMail installed on our server though, but not many of our users use that, preferring to pop from home. I suppose we could put some instructions up where the user would view the message source, paste that into web form and that would get piped directly into sa-learn and then into the SQL bayes database. It's pernickerty but it would work, and relies on the sitewide SQL database working. Gaby -- Ha! Ha! Ha! Dislocation... - Phil Ken Sebben [EMAIL PROTECTED] http://vanhegan.net
Re: ?
On Tue, Nov 02, 2004 at 03:45:08PM +0300, Alexandr Orlov wrote: I love spamassasin, but I hate this: X-Spam-Status: SpamAssassin Failed I look to the log file, to the debug, soo at all, but I can`t find anything? What can give this error? Nothing from SpamAssassin writes that header. It is caused by whatever you use to call SpamAssassin. -- Randomly Generated Tagline: There is, however, a strange, musty smell in the air that reminds me of something...hmm...yes...I've got it...there's a VMS nearby, or I'm a Blit. -- Larry Wall in Configure from the perl distribution pgp4Nf0D434Iz.pgp Description: PGP signature
RE: Error after upgrading to 3.0.1
-Original Message- From: marti [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 11:46 AM To: Spamassassin Subject: RE: Error after upgrading to 3.0.1 |-Original Message- |From: Keith Hackworth [mailto:[EMAIL PROTECTED] |Sent: 02 November 2004 15:40 |To: marti |Cc: Spamassassin |Subject: Re: Error after upgrading to 3.0.1 | | After upgrading from 3.0.0 to the latest version I get the following | error:- | | ERROR! spamassassin script is v3.00, but using modules |v3.01! | | Any idea what scrip its refering to, spamassassin --lint -D worked | just fine, but cant fire up spamd. | | Martin | | | |I had the same problem - copy the files from /opt/local/scripts to |/opt/local/bin | |Keith | I don't have such a directory, it installs to /usr/lib/perl5/site_perl/5.8.0/Mail /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin /usr/bin/spamc /usr/bin/spamd /etc/mail/spamassassin Using locate I can confirm there are no other directories other than a backup directory I put all the rules in, so can only think that it dosent like one of the scripts that came in the Mail-SpamAssassin-3.0.1.tar.gz. What do you class as a script, is that a .cf? or could that be any file in the package? Is there anyway to get a debug output from spamd so I can see which script its borking on? I have run out of ideas now as to whats causing this, is there a bug in make install, this should just be a simple process, this is ridiculous. Martin Keith is right; the script is looking for the new scripts in the old place. Mine were in /usr/local/bin and /usr/bin. Just move or copy the new scripts in the directory the old ones are in.
RE: Error after upgrading to 3.0.1
| |Keith is right; the script is looking for the new scripts in |the old place. |Mine were in /usr/local/bin and /usr/bin. |Just move or copy the new scripts in the directory the old ones are in. | | I would if it had installed them in a different place but its not, I forgot to put the rules path which is /usr/share/spamassassin and looking at the .cf rules they say require_version 3.01 apart from 10_misc.cf which doesn't have a require_version in it
RE: Error after upgrading to 3.0.1
|-Original Message- |From: Keith Hackworth [mailto:[EMAIL PROTECTED] |Sent: 02 November 2004 15:40 |To: marti |Cc: Spamassassin |Subject: Re: Error after upgrading to 3.0.1 | | After upgrading from 3.0.0 to the latest version I get the following | error:- | | ERROR! spamassassin script is v3.00, but using modules |v3.01! | | Any idea what scrip its refering to, spamassassin --lint -D worked | just fine, but cant fire up spamd. | | Martin | | | |I had the same problem - copy the files from |/opt/local/scripts to /opt/local/bin | |Keith | I don't have such a directory, it installs to /usr/lib/perl5/site_perl/5.8.0/Mail /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin /usr/bin/spamc /usr/bin/spamd /etc/mail/spamassassin Using locate I can confirm there are no other directories other than a backup directory I put all the rules in, so can only think that it dosent like one of the scripts that came in the Mail-SpamAssassin-3.0.1.tar.gz. What do you class as a script, is that a .cf? or could that be any file in the package? Is there anyway to get a debug output from spamd so I can see which script its borking on? I have run out of ideas now as to whats causing this, is there a bug in make install, this should just be a simple process, this is ridiculous. Martin When I got this error, it meant I had 2 copies of spamassassin executable installed on my system with one set of libraries. When I installed SA on my Solaris system running perl 5.8.4 from CPAN (perl -MCPAN -e shell\n CPAN install SpamAssassin), it created all the scripts (spamassassin, spamd, spamc, etc) in a directory /opt/local/scripts instead of /opt/local/bin (where it had installed all previous versions). If you do a which spamassassin and spamassassin --version, it'll more than likely say 3.0.0 (or some other back-rev version). I figured this out by looking at the install output to see exactly where it put the spamassassin executables and realized it wasn't in /opt/local/bin. I had to move the scripts to the /opt/local/bin directory by hand. Keith
Re:
On Tue, Nov 02, 2004 at 08:42:34AM -0500, Matt Kettler wrote: ... X-Spam-Status: SpamAssassin Failed ... What can give this error? ON 29th of October Alexandr Orlov [EMAIL PROTECTED] also wrote a Question to the list, containig the same Header. He said I have a linux box with CommunigatePro + spamassasin. So may be you'll find the same Problem at your site, and that 'CommunigatePro' MTA does not understand spamassassin2 ? Just an Idea, because I stumbled upon the older Message while cleaning mailfolders :-) Stucki -- Christoph von Stuckrad * * |nickname |[EMAIL PROTECTED]\ Freie Universitaet Berlin |/_*|'stucki' |Tel(days):+49 30 838-75 459| Fachbereich Mathematik, EDV|\ *|if online|Tel(else):+49 30 77 39 6600| Arnimallee 2-6/14195 Berlin* * |on IRCnet|Fax(alle):+49 30 838-75454/
Re:
From the looks of it, it's generated by this tool: http://groups.google.com/groups?q=%22X-Spam-Status:+SpamAssassin+Failed%22+Communigatehl=enlr=selm=list-25424187%40mail.stalker.comrnum=1 It inserts an X-Spam-Status header, and expects SpamAssassin to over-write it. If for some reason SA doesn't get called, the failed message stays. In this case failed is a bit of a misnomer. It could mean SA failed, or that SA was never called at all due to some kind of bypass rule in the CG configuration. At 11:59 AM 11/2/2004, Chr. von Stuckrad wrote: On Tue, Nov 02, 2004 at 08:42:34AM -0500, Matt Kettler wrote: ... X-Spam-Status: SpamAssassin Failed ... What can give this error? ON 29th of October Alexandr Orlov [EMAIL PROTECTED] also wrote a Question to the list, containig the same Header. He said I have a linux box with CommunigatePro + spamassasin. So may be you'll find the same Problem at your site, and that 'CommunigatePro' MTA does not understand spamassassin2 ? Just an Idea, because I stumbled upon the older Message while cleaning mailfolders :-) Stucki -- Christoph von Stuckrad * * |nickname |[EMAIL PROTECTED]\ Freie Universitaet Berlin |/_*|'stucki' |Tel(days):+49 30 838-75 459| Fachbereich Mathematik, EDV|\ *|if online|Tel(else):+49 30 77 39 6600| Arnimallee 2-6/14195 Berlin* * |on IRCnet|Fax(alle):+49 30 838-75454/
Re: trusted_networks and ALL_TRUSTED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sean Doherty writes: On Mon, 2004-11-01 at 19:28, Justin Mason wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Maul writes: This is exactly how i have my system setup. I have a 192.168 IP assigned to my server. It has no public IP assigned to it. However, i have a router/firewall in front of it which has a public ip assigned to its wan interface which then does NAT/port forwarding to my qmail server. It works extremely well for our purposes. It sounds to me that if i upgraded to 3.0 (still running 2.64) i would then have the same issue with the trusted networks. It doesnt really sound correct. Just because my machine doesnt have a public ip does NOT mean that mail passes through a trusted source first..unless you are calling my little SMC barricade a trusted source. there's a very easy way to deal with this, and it's what you should use. set trusted_networks. That's exactly why there's a parameter there to set ;) Basically, SpamAssassin can't know all about your network setup unless you tell it. it'll try to guess, but there's only so far guessing will go, and without information from you, it's pretty much impossible to guess this. So shouldn't SpamAssassin take a conservative approach when guessing, and advising via the debug output that the user should set trusted_networks. probably. it's documented all over the Mail::SpamAssassin::Conf man page and the UPGRADE file... - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBh8QDMJF5cimLx9ARAiy4AJsFLDp/D0Di13xZlIh6OJ+S1WXyGgCgq9mN DIAZkF9PYi/Ki/YZy5oWQLM= =kzbp -END PGP SIGNATURE-
RE: Error after upgrading to 3.0.1
|-Original Message- |From: Keith Hackworth [mailto:[EMAIL PROTECTED] |Sent: 02 November 2004 16:57 |To: marti |Cc: Spamassassin |Subject: RE: Error after upgrading to 3.0.1 | | |When I got this error, it meant I had 2 copies of spamassassin |executable installed on my system with one set of libraries. | |When I installed SA on my Solaris system running perl 5.8.4 |from CPAN (perl -MCPAN -e shell\n CPAN install SpamAssassin), |it created all the scripts (spamassassin, spamd, spamc, etc) |in a directory /opt/local/scripts instead of /opt/local/bin |(where it had installed all previous versions). If you do a |which spamassassin and spamassassin --version, it'll more |than likely say 3.0.0 (or some other back-rev version). I |figured this out by looking at the install output to see |exactly where it put the spamassassin executables and realized |it wasn't in /opt/local/bin. I had to move the scripts to the |/opt/local/bin directory by hand. | |Keith | Well I tried the install via CPAM but with the exact same result All I can do is reiterate that I don't have 2 locations for old and new install they are both installed in same directory, the .cf say they are the new version but still get ERROR! spamassassin script is v3.00, but using modules v3.01! Surely spamassassin dosent scan the HDD for all .cf ? The only old files I have are by backup files in another directory. Can anyone else suggest whats going on?
RE: Error after upgrading to 3.0.1
|-Original Message- |From: Keith Hackworth [mailto:[EMAIL PROTECTED] |Sent: 02 November 2004 16:57 |To: marti |Cc: Spamassassin |Subject: RE: Error after upgrading to 3.0.1 | | |When I got this error, it meant I had 2 copies of spamassassin |executable installed on my system with one set of libraries. | |When I installed SA on my Solaris system running perl 5.8.4 |from CPAN (perl -MCPAN -e shell\n CPAN install SpamAssassin), |it created all the scripts (spamassassin, spamd, spamc, etc) |in a directory /opt/local/scripts instead of /opt/local/bin |(where it had installed all previous versions). If you do a |which spamassassin and spamassassin --version, it'll more |than likely say 3.0.0 (or some other back-rev version). I |figured this out by looking at the install output to see |exactly where it put the spamassassin executables and realized |it wasn't in /opt/local/bin. I had to move the scripts to the |/opt/local/bin directory by hand. | |Keith | Well I tried the install via CPAM but with the exact same result All I can do is reiterate that I don't have 2 locations for old and new install they are both installed in same directory, the .cf say they are the new version but still get ERROR! spamassassin script is v3.00, but using modules v3.01! Surely spamassassin dosent scan the HDD for all .cf ? The only old files I have are by backup files in another directory. Can anyone else suggest whats going on? This has nothing to do with .cf files. It is purely a problem with running the wrong version of sa. Do this: find / --name spamassassin --print It will show all instances of spamassassin (unfortunately, it will also give you time to go to lunch) Run each of these instances with a --version argument and see what happens. Keith
Re: Per-user capabilities
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Khalid Waheed writes: SpamAssassin has all sorts of per-user capabilities, including whitelists, rule weights, and Bayesian filtering. But all of this stuff is totally useless in some mail servers (e.g. SunOne messaging server), for the simple reason that being able to process mail for multiple users simultaneously is an absolutely critical capability, and SpamAssassin is simply not designed to offer this capability. yep. However you should examine what proportion of mail nowadays, arriving from the internet, *is* addressed to multiple users in the one SMTP transaction. This may appear to be a major failing, but in my experience it's just not, in real-world use. Sounds like SunOne needs an interface that can cope with that. - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBh8eFMJF5cimLx9ARAgjqAJwOlA5dcZtkfdaiSYh50Q1OGWDkJwCfdWh4 AYmAeihvbFxD2b8/K1M4Rn8= =E89Z -END PGP SIGNATURE-
Re: ?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alexandr Orlov writes: I love spamassasin, but I hate this: X-Spam-Status: SpamAssassin Failed I look to the log file, to the debug, soo at all, but I can`t find anything? What can give this error? never heard of it -- it's not SpamAssassin itself, it's some app that is running it. - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBh8ekMJF5cimLx9ARAuVyAKCRHGySkta7+TSEYsDbdCAwo+TjngCffqZO ZDZENNQKYz64rm1A5GQfhMQ= =ovHc -END PGP SIGNATURE-
RE: Error after upgrading to 3.0.1
|-Original Message- |From: Keith Hackworth [mailto:[EMAIL PROTECTED] |Sent: 02 November 2004 16:57 |To: marti |Cc: Spamassassin |Subject: RE: Error after upgrading to 3.0.1 | | |When I got this error, it meant I had 2 copies of spamassassin |executable installed on my system with one set of libraries. | |When I installed SA on my Solaris system running perl 5.8.4 |from CPAN (perl -MCPAN -e shell\n CPAN install SpamAssassin), |it created all the scripts (spamassassin, spamd, spamc, etc) |in a directory /opt/local/scripts instead of /opt/local/bin |(where it had installed all previous versions). If you do a |which spamassassin and spamassassin --version, it'll more |than likely say 3.0.0 (or some other back-rev version). I |figured this out by looking at the install output to see |exactly where it put the spamassassin executables and realized |it wasn't in /opt/local/bin. I had to move the scripts to the |/opt/local/bin directory by hand. | |Keith | Well I tried the install via CPAM but with the exact same result All I can do is reiterate that I don't have 2 locations for old and new install they are both installed in same directory, the .cf say they are the new version but still get ERROR! spamassassin script is v3.00, but using modules v3.01! Surely spamassassin dosent scan the HDD for all .cf ? The only old files I have are by backup files in another directory. Can anyone else suggest whats going on? This has nothing to do with .cf files. It is purely a problem with running the wrong version of sa. Do this: find / --name spamassassin --print It will show all instances of spamassassin (unfortunately, it will also give you time to go to lunch) Run each of these instances with a --version argument and see what happens. Keith argh!! Sorry - try this: find / -name spamassassin -print Leave off the double hypens...
Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 George Georgalis writes: On Tue, Nov 02, 2004 at 01:03:02PM +, Sean Doherty wrote: On Tue, 2004-11-02 at 12:50, George Georgalis wrote: Do you mean -0.001? Why would you want to penalise mail coming thru a trusted path? It really doesn't matter to me what the score is, I just want to disable the test. http://bugzilla.spamassassin.org/show_bug.cgi?id=3406 My /etc/spamassassin is the reference I replicate out to my other systems, and systems of my clients, which may or may not be on nat and certainly are on different networks. The setup I use routes mail at the tcp level, it's basically impossible for a message to reach spam assassin if it's from a trusted network. So why not set trusted_networks to 127.0.0.1. That way you can be certain that the rule will never fire. You'll also get the benefit of the DNS blocklists been checked for the addresses in the Received headers - with your current setup, its possible that some of these will be marked as trusted, and as such you'll lose the benefit of the RBL check. There is lots of reasons not to do something. What I'm not seeing is a reason why I can't stop trusted_networks from using cpu/dns. your idea sounds okay for some applications (and I'm changing from 192.168 to 127.0.0.1 as a matter of course), but I don't want every address in headers looked up. I don't want any of them looked up. I hope it's okay for me to be that way. Use -L. I am concerned about the IP a message is coming from, but in my setup, that is dealt with before SA ever sees the message. // George - --j. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Exmh CVS iD8DBQFBh8gPMJF5cimLx9ARAj3tAJsHhoing635RRoUfrBYpcfO6fUbegCbBool mZN44dP3FUspuEVV58K9knE= =gJ+v -END PGP SIGNATURE-
Re: AWL and ABL Re: trusted_networks and ALL_TRUSTED
On Tue, Nov 02, 2004 at 09:46:55AM -0800, Justin Mason wrote: George Georgalis writes: On Tue, Nov 02, 2004 at 01:03:02PM +, Sean Doherty wrote: On Tue, 2004-11-02 at 12:50, George Georgalis wrote: Do you mean -0.001? Why would you want to penalise mail coming thru a trusted path? It really doesn't matter to me what the score is, I just want to disable the test. http://bugzilla.spamassassin.org/show_bug.cgi?id=3406 My /etc/spamassassin is the reference I replicate out to my other systems, and systems of my clients, which may or may not be on nat and certainly are on different networks. The setup I use routes mail at the tcp level, it's basically impossible for a message to reach spam assassin if it's from a trusted network. So why not set trusted_networks to 127.0.0.1. That way you can be certain that the rule will never fire. You'll also get the benefit of the DNS blocklists been checked for the addresses in the Received headers - with your current setup, its possible that some of these will be marked as trusted, and as such you'll lose the benefit of the RBL check. There is lots of reasons not to do something. What I'm not seeing is a reason why I can't stop trusted_networks from using cpu/dns. your idea sounds okay for some applications (and I'm changing from 192.168 to 127.0.0.1 as a matter of course), but I don't want every address in headers looked up. I don't want any of them looked up. I hope it's okay for me to be that way. Use -L. I had until I recently integrated SURBL, which is not compatable with -L. // George -- George Georgalis, systems architect, administrator Linux BSD IXOYE http://galis.org/george/ cell:646-331-2027 mailto:[EMAIL PROTECTED]
RE: Error after upgrading to 3.0.1
|-Original Message- |From: Keith Hackworth [mailto:[EMAIL PROTECTED] |Sent: 02 November 2004 17:43 |To: marti |Cc: Spamassassin |Subject: RE: Error after upgrading to 3.0.1 | |This has nothing to do with .cf files. It is purely a problem |with running the wrong version of sa. | |Do this: find / --name spamassassin --print | |It will show all instances of spamassassin (unfortunately, it |will also give you time to go to lunch) | |Run each of these instances with a --version argument and see |what happens. | |Keith | Ok thanks for your patience Keith, you pointed me in the right direction, spamassassin wasn't he problem, I had 2 spamd, one in /usr/bin/spamd and another in /usr/sbin/spamd, one the old and one the new. All up and running on the new one now :) Martin
RE: Error after upgrading to 3.0.1
|-Original Message- |From: Keith Hackworth [mailto:[EMAIL PROTECTED] |Sent: 02 November 2004 17:43 |To: marti |Cc: Spamassassin |Subject: RE: Error after upgrading to 3.0.1 | |This has nothing to do with .cf files. It is purely a problem |with running the wrong version of sa. | |Do this: find / --name spamassassin --print | |It will show all instances of spamassassin (unfortunately, it |will also give you time to go to lunch) | |Run each of these instances with a --version argument and see |what happens. | |Keith | Ok thanks for your patience Keith, you pointed me in the right direction, spamassassin wasn't he problem, I had 2 spamd, one in /usr/bin/spamd and another in /usr/sbin/spamd, one the old and one the new. All up and running on the new one now :) Martin That's good news! FYI: You're going to run into the same problem with sa-learn and the other scripts shipped with SA. Make sure you remove them from the old directory (I'm guessing /usr/bin). Keith
Re: Sitewide Bayes DB, spam mailbox
After some more rumbling around today, I've come across this; http://www.stearns.org/doc/spamassassin-setup.current.html And in interesting section on Shared whitelist and bayes databases and autoreporting addresses, which seems to cover most of what I want to do. To this end, I've setup a spam mailbox and a nospam mailbox, and I have installed the redirector plugin for Thunderbird: http://mailredirect.mozdev.org/installation.html Which allows me to bounce messages with unfettered headers, straight to a mailbox that drops it directly into spamassassin -r -d -a, which in turn goes into a site-wide bayes DB. Ergo, if I bounce some spam to that address, the mail server will then filter it for all accounts on the machine :) And to prevent abuse of this mechanism, it's setup so that only certain people can report spam to this mailbox (me, and the other admin). Nice. Gaby -- Ha! Ha! Ha! Dislocation... - Phil Ken Sebben [EMAIL PROTECTED] http://vanhegan.net
Re: Automatic rejection
From: Matt Kettler [EMAIL PROTECTED]
At 01:24 PM 11/2/2004 +, Moussa Fall wrote:
Thank you, Martin and Duncan!
Sorry I did not mention this information. I am using RH9 with Postfix.
Maybe I can use Mailscanner.
Regardless of objections to using MailScanner with postfix (not supported
by the postfix guys, but does seem to work for a lot of people) Don't
*ever* use mailscanner's bounce feature.. It's broken beyond belief and
makes your server into a DDoS tool. (Expands the scope of a Joe-job from a
single-source DoS to a multi-source DDoS)
Many in the community, myself included, asked Julian to remove this
feature, but at least one large site admin with a I don't care who's site
I DDoS, I want to bounce them because this makes mail 'reliable'...
attitude insisted he leave it in. So Julian deferred to adding a few extra
hoops to enable the feature.
It tends to get this large ISP tossed into my .procmailrc spam recipe
that tosses sites that routinely bounce spam to me to /dev/null. A
nice reliable bounce site is invaluable to spammers. Would you care to
tell me which ISP this is?
I myself have a standing policy of blacklisting with a 550 nastygram any
server generating more than two such messages in a 24 hour period as a
defensive measure.
It only takes one bounce that is a spam when opened for me to consign the
entire ISP to /dev/null.
{o.o}
Re: Automatic rejection
At 03:08 PM 11/2/2004, jdow wrote: From: Matt Kettler [EMAIL PROTECTED] At 01:24 PM 11/2/2004 +, Moussa Fall wrote: Thank you, Martin and Duncan! Sorry I did not mention this information. I am using RH9 with Postfix. Maybe I can use Mailscanner. Regardless of objections to using MailScanner with postfix (not supported by the postfix guys, but does seem to work for a lot of people) Don't *ever* use mailscanner's bounce feature.. It's broken beyond belief and makes your server into a DDoS tool. (Expands the scope of a Joe-job from a single-source DoS to a multi-source DDoS) Many in the community, myself included, asked Julian to remove this feature, but at least one large site admin with a I don't care who's site I DDoS, I want to bounce them because this makes mail 'reliable'... attitude insisted he leave it in. So Julian deferred to adding a few extra hoops to enable the feature. It tends to get this large ISP tossed into my .procmailrc spam recipe that tosses sites that routinely bounce spam to me to /dev/null. A nice reliable bounce site is invaluable to spammers. Would you care to tell me which ISP this is? The bounce feature was re-introduced (Julian had removed it) after a long thread started by this guy: James Sizemore of Deny.org: http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0402L=mailscannerP=R31065I=-1 http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0402L=mailscannerP=R32998I=-1 http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0402L=mailscannerP=R33252I=-1 Looking at the whois records for Deny.org, and some usenet postings, James works for isdn.net, and ISP in TN, USA. And also in support of the feature was Admin Team of ENHTECH.com: http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0402L=mailscannerP=R33398I=-1 http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0402L=mailscannerD=0I=-1P=61971 I myself have a standing policy of blacklisting with a 550 nastygram any server generating more than two such messages in a 24 hour period as a defensive measure. It only takes one bounce that is a spam when opened for me to consign the entire ISP to /dev/null. True, although I'll admit that so far I have yet to get any garbage mail from the servers of these networks. Who knows, maybe they thought better of it after getting clue-by-foured with 550's by someone.
Re: Automatic rejection
At 03:39 PM 11/2/2004, Matt Kettler wrote: Looking at the whois records for Deny.org, and some usenet postings, James works for isdn.net, and ISP in TN, USA. Self clarification, it appears James worked for isdn.net at the time. I have no idea if James still works there, or to what degree he represents the views of his employer, etc. Also be sure to read the whole thread, it's quite interesting. There's lots of solutions proposed which more-or-less miss the entire point of the problem being resource exhaustion. i.e: thinking the problem is calling it spam, and that kinder wording would solve the problem. Thinking that adding headers to the message to act as filtering aids would solve the problem, etc.
Problems with SURBL and catching stuff..
Hi, Perhaps someone can help here. I have recently added the SURBL functionality to my SpamAssassin installation, and things seem to work wonderfully. However, we do on a fairly regular basis seem to be the first to get hit with the spam. What I mean is that spamassassin will catch it only scoring around 2.3 or so.. based on mostly images and HTML, but won't get the URL or score it past 5 points.A few hours later if I run the URL through an e-mail it will come up [SPAM]. Any suggestions how to get these mails marked as spam ? I don't want to set my score criterion too low to avoid FPs.
2.64 spamc with 3.0.1 spamd
2.64 spamc on toasters with 3.0.1 spamd running on NFS server. Currently we are all 2.64, but I am planning to upgrade the NFS box tonight to 3.0.1 Anyone tried it? I hope I do not have to go and rebuild all my toasters. It looks as though it should be fine, we use no Bayes, no AWL. Just tought I would ask before I try it ;^) DAve -- Systems Administrator http://www.tls.net Get rid of Unwanted Emails...get TLS Spam Blocker!
SA headers suddenly stopped appearing in List mails.
Hi All, Did anything change in the SA lists since Sunday? Have had SA 3.0 running happily here since it came out (win32/cygwin) - from Sunday I started seeing mail from the list (and annoyingly some 419ers too) with no SA headers at all - a check of the logs for spamd shows it never even saw the emails. Since this started Sunday and, so far, I've made no changes to either mail or SA, I'm assuming the change must be elsewhere (I'm hoping to hell the change was at the list side and I just missed something) Any and all help gratefully received. Nigel.
Re: 2.64 spamc with 3.0.1 spamd
On Tue, Nov 02, 2004 at 04:46:47PM -0500, Dave Goodrich wrote: Anyone tried it? I hope I do not have to go and rebuild all my toasters. It looks as though it should be fine, we use no Bayes, no AWL. I haven't tried it, but the spamd protocol wasn't changed between v2 and v3, so the old spamc binaries ought to continue working for you. I can't recall if there were any spamc modifications (bug fixes, etc,) though, so you may want to upgrade them in the future. -- Randomly Generated Tagline: L'etat ... C'est moo. - Unknown pgpvnZnL0dtSo.pgp Description: PGP signature
Re: CFLAGS
On Mon, 1 Nov 2004 14:20:35 -0500, Michael Barnes wrote I was able to change the default CFLAGS by putting the CCFLAGS and the CFLAGS values in my environment before running perl Makefile.PL. I would guess that this could be considered a bug, because its not too uncommon for default CFLAGS to be changed during a compilation. You were right. It has to go in the environment. In other words, this doesn't work: # perl Makefile.PL CCFLAGS=-O # make But this does: # perl Makefile.PL # CFLAGS=-O make
This is driving me NUTS
Hi all, I don't know what I did, but this is what's happening to me 1. SpamAssassin noi longer Prepend Subject Line even though I told it to in local.cf 2. Spam score mismatch in headers. 3. Spam gets delivered as it is but Spamassassin report was send as an attachment instead of the other way around! Please help. This is my setup Fedora Core 2 SpamAssassin 3 Mimedefang 3.48 ClamAV 0.8 Many Thanks! Yang ---Sample Mail Header Received: from mail.domain.com (192.168.2.111 [192.168.2.111]) by mail.ohpp.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2657.72) id VLSN5ZAB; Tue, 2 Nov 2004 17:18:09 -0500 Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.192]) by mail.domain.com (8.12.11/8.12.11) with ESMTP id iA2MJBU5021808 for [EMAIL PROTECTED]; Tue, 2 Nov 2004 17:19:13 -0500 Received: by wproxy.gmail.com with SMTP id 66so89085wri for [EMAIL PROTECTED]; Tue, 02 Nov 2004 14:19:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=EFkIA1O6m6xKEFDXjFBPzrUROzzjTFvbnmXvPhQb+9qzLdDugN4g7dnGN+K2d10tX93Y+wwPC5goJ51JN9DL9sucPQ5hitkLZjzs4jqdzra8KHM/9blM5etbiu3k7wACwaDMKX9UVAsIuiBb5CsGlkQsrlnwPMFFw/1TLQ4J60k= Received: by 10.54.50.22 with SMTP id x22mr134736wrx; Tue, 02 Nov 2004 14:19:06 -0800 (PST) Received: by 10.54.22.65 with HTTP; Tue, 2 Nov 2004 14:19:06 -0800 (PST) Message-ID: [EMAIL PROTECTED] Date: Tue, 2 Nov 2004 17:19:06 -0500 From: Yang Xiao [EMAIL PROTECTED] Reply-To: Yang Xiao [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Fwd: Congratulations In-Reply-To: [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: multipart/mixed; boundary=--=_1099433954-21740-0 References: [EMAIL PROTECTED] X-Spam-Score: ** (6.309) BILLION_DOLLARS,DEAR_SOMETHING,FROM_ENDS_IN_NUMS,NIGERIAN_BODY1,NIGERIAN_BODY2 X-Scanned-By: MIMEDefang 2.48 on 192.168.2.111 X-Virus-Scanned: ClamAV 0.80/569/Tue Nov 2 14:14:23 2004 clamav-milter version 0.80j on mail.domain.com X-Virus-Status: Clean X-Spam-Status: No, score=3.1 required=5.0 tests=ALL_TRUSTED,BILLION_DOLLARS, DEAR_SOMETHING,FROM_ENDS_IN_NUMS,NIGERIAN_BODY1,NIGERIAN_BODY2, RCVD_BY_IP autolearn=no version=3.0.1 X-Spam-Level: *** X-Spam-Checker-Version: SpamAssassin 3.0.1 (2004-10-22) on mail.domain.com This is a multi-part message in MIME format... =_1099433954-21740-0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Disposition: inline =_1099433954-21740-0 Content-Type: text/plain; name=SpamAssassinReport.txt Content-Disposition: inline; filename=SpamAssassinReport.txt Content-Transfer-Encoding: 7bit MIME-Version: 1.0 X-Mailer: MIME-tools 5.415 (Entity 5.415)
Spamd broken since 3.0.x
Since the cpanel upgrade to spamd 3.0.x i have been having hell with this one machine, i have over 500 other machines working just fine but this one is just stuborn. The machine is a older one, Redhat 8.0, Perl was recently upgraded to 5.8.4 in hopes of solving the problem. Below is a debug dump of the problem Here are some of the things i have tryed. Removed /usr/lib/perl5/site_perl/5.8.4/Mail/SpamAssassin and reinstalled SpamAssassin Upgraded Perl sa-learn --sync for all users and some other things. When 3.0.0 was around i could tmp fix/patch up the problem by forcing Mail::SpamAssassin and then forcing Mail::SpamAssassin:Conf but that doesnt work anymore. Sorry if this issue has been covered, i've searched around like a mad man and having found really anything. ## OUTPUT [EMAIL PROTECTED] [/usr/bin]# /usr/bin/spamd -D trying to connect to syslog/unix... no error connecting to syslog/unix logging enabled: facility: mail socket: unix output: syslog creating INET socket: Listen: 128 LocalAddr: 127.0.0.1 LocalPort: 783 Proto: 6 ReuseAddr: 1 Type: 1 debug: SpamAssassin version 3.0.1 debug: Score set 0 chosen. debug: Storable module v2.13 found debug: Preloading modules with HOME=/tmp/spamd-1151-init debug: ignore: test message to precompile patterns and load modules debug: using /etc/mail/spamassassin/init.pre for site rules init.pre debug: config: read file /etc/mail/spamassassin/init.pre debug: using /usr/share/spamassassin for default rules dir debug: config: read file /usr/share/spamassassin/10_misc.cf debug: config: read file /usr/share/spamassassin/20_anti_ratware.cf debug: config: read file /usr/share/spamassassin/20_body_tests.cf debug: config: read file /usr/share/spamassassin/20_compensate.cf debug: config: read file /usr/share/spamassassin/20_dnsbl_tests.cf debug: config: read file /usr/share/spamassassin/20_drugs.cf debug: config: read file /usr/share/spamassassin/20_fake_helo_tests.cf debug: config: read file /usr/share/spamassassin/20_head_tests.cf debug: config: read file /usr/share/spamassassin/20_html_tests.cf debug: config: read file /usr/share/spamassassin/20_meta_tests.cf debug: config: read file /usr/share/spamassassin/20_phrases.cf debug: config: read file /usr/share/spamassassin/20_porn.cf debug: config: read file /usr/share/spamassassin/20_ratware.cf debug: config: read file /usr/share/spamassassin/20_uri_tests.cf debug: config: read file /usr/share/spamassassin/23_bayes.cf debug: config: read file /usr/share/spamassassin/25_body_tests_es.cf debug: config: read file /usr/share/spamassassin/25_hashcash.cf debug: config: read file /usr/share/spamassassin/25_spf.cf debug: config: read file /usr/share/spamassassin/25_uribl.cf debug: config: read file /usr/share/spamassassin/30_text_de.cf debug: config: read file /usr/share/spamassassin/30_text_fr.cf debug: config: read file /usr/share/spamassassin/30_text_nl.cf debug: config: read file /usr/share/spamassassin/30_text_pl.cf debug: config: read file /usr/share/spamassassin/50_scores.cf debug: config: read file /usr/share/spamassassin/60_whitelist.cf debug: using /etc/mail/spamassassin for site rules dir debug: config: read file /etc/mail/spamassassin/local.cf debug: plugin: loading Mail::SpamAssassin::Plugin::URIDNSBL from @INC debug: plugin: registered Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) debug: plugin: loading Mail::SpamAssassin::Plugin::Hashcash from @INC debug: plugin: registered Mail::SpamAssassin::Plugin::Hashcash=HASH(0x8ad6d84) debug: plugin: loading Mail::SpamAssassin::Plugin::SPF from @INC debug: plugin: registered Mail::SpamAssassin::Plugin::SPF=HASH(0x8ab2184) debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) implements 'parse_config' debug: plugin: Mail::SpamAssassin::Plugin::Hashcash=HASH(0x8ad6d84) implements 'parse_config' debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x84197d8) inhibited further callbacks debug: plugin:
Re: Spamd broken since 3.0.x
On Tue, Nov 02, 2004 at 02:33:23PM -0800, Shaun wrote: Use of uninitialized value in numeric eq (==) at /usr/lib/perl5/site_perl/5.8.4/Mail/SpamAssassin/Conf/Parser.pm line 730. This means the rule has no type. Likely it's a bad configuration. (I'd like to know what it is though since I didn't think it was possible to have an undef type...) debug: config: SpamAssassin failed to parse line, no value provided for describe, skipping: describe IN_NJABL_ORG debug: config: SpamAssassin failed to parse line, no value provided for tflags, skipping: tflags IN_NJABL_ORG you have invalid configuration options. debug: config: SpamAssassin failed to parse line, no value provided for describe, skipping: describe NJABL_OPEN_RELAY debug: config: SpamAssassin failed to parse line, no value provided for tflags, skipping: tflags NJABL_OPEN_RELAY ditto. debug: config: SpamAssassin failed to parse line, no value provided for describe, skipping: describe NJABL_DUL debug: config: SpamAssassin failed to parse line, no value provided for tflags, skipping: tflags NJABL_DUL ditto ... Judging by the debug output, you have NJABL rules which are invalid. Remove them and try again. -- Randomly Generated Tagline: Sorry, Mr. Burns, but I don't go in for these backdoor shenanigans. Sure I'm flattered, maybe even a little curious, but the answer is no! -- Homer Simpson Last Exit to Springfield pgpKHTdAJTzPE.pgp Description: PGP signature
Re: Problems with SURBL and catching stuff..
Hi! Perhaps someone can help here. I have recently added the SURBL functionality to my SpamAssassin installation, and things seem to work wonderfully. However, we do on a fairly regular basis seem to be the first to get hit with the spam. What I mean is that spamassassin will catch it only scoring around 2.3 or so.. based on mostly images and HTML, but won't get the URL or score it past 5 points.A few hours later if I run the URL through an e-mail it will come up [SPAM]. Any suggestions how to get these mails marked as spam ? I don't want to set my score criterion too low to avoid FPs. Most likely the URL is added to SURBL later on ? Bye, Raymond.
RE: 2.64 spamc with 3.0.1 spamd
It is safe to use SA 2.x SpamC with SA 3.x SpamD. Jason J Ellingson Technical Consultant 615.301.1682 : nashville 612.605.1132 : minneapolis www.ellingson.com [EMAIL PROTECTED] -Original Message- From: Theo Van Dinter [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 02, 2004 3:55 PM To: users@spamassassin.apache.org Subject: Re: 2.64 spamc with 3.0.1 spamd On Tue, Nov 02, 2004 at 04:46:47PM -0500, Dave Goodrich wrote: Anyone tried it? I hope I do not have to go and rebuild all my toasters. It looks as though it should be fine, we use no Bayes, no AWL. I haven't tried it, but the spamd protocol wasn't changed between v2 and v3, so the old spamc binaries ought to continue working for you. I can't recall if there were any spamc modifications (bug fixes, etc,) though, so you may want to upgrade them in the future. -- Randomly Generated Tagline: L'etat ... C'est moo. - Unknown
