Re: OT - abuseat.org
* Nigel Frankcom [EMAIL PROTECTED]: Hi All, This may be old news, but... anyone using abuseseat.org in their RBL's should probably remove it. I had it running here in my main server config (so not an SA issue) and it's been 550ing every incoming email. A quick check of the domain shows nothing there at all. http://cbl.abuseat.org/ -- Ralf Hildebrandt (i.A. des IT-Zentrums) [EMAIL PROTECTED] Charite - Universitätsmedizin BerlinTel. +49 (0)30-450 570-155 Gemeinsame Einrichtung von FU- und HU-BerlinFax. +49 (0)30-450 570-962 IT-Zentrum Standort CBF send no mail to [EMAIL PROTECTED]
spamc command line option -f
Hello, i just installed spamassassin on my mailserver, which runs postfix. I used http://wiki.apache.org/spamassassin/IntegratedSpamdInPostfix for an howto to integrate SA within postfix. In this wiki-article there is a command line option -f for spamc which i can not found in the manpage. So i do not know whats it good for. Can someone pls explain this to me ? regards Joerg -- Joerg Hartmann Mercateo 06366 Koethen, Museumsgasse 4/5 Tel: +49 3496 512 100
Oddities since change to 3.1
I am getting Sep 21 09:34:20 snout spamd[28958]: mkdir /nonexistent: Permission denied at /usr/local/share/perl/5.8.4/Mail/SpamAssassin.pm line 1467 Sep 21 09:34:20 snout spamd[28958]: locker: safe_lock: cannot create tmp lockfile /nonexistent/.spamassassin/auto-whitelist.lock.snout.codemist.co.uk.28958 for /nonexistent/.spamassassin/auto-whitelist.lock: No such file or directory Sep 21 09:34:20 snout spamd[28958]: Can't call method finish on an undefined value at /usr/local/share/perl/5.8.4/Mail/SpamAssassin/Plugin/AWL.pm line 397. This was installed from source like all previous versions of SA, and this is the first time I have had problems. I tried to look at teh UPGRADE file and it did not seem to make much sense to me. ==John ffitch
Bayes expiry/oddity
I'm running a reasonably small site-wide spamassassin, and I use a site-side bayes db. Spamassassin runs as the user spamd. I noticed that I got spam last night with no BAYES_XX markup. I looked into it this morning, and discovered that the bayes db only has 47 spam messages in it (nspam from sa-learn --dump magic). It has about 69000 ham. It must have gone from 200 spams at around 11pm last night to 50 this morning, and the only explanation I can think of is that the spam has been expired, but on the other hand this seems odd. Spamassassin learnt 143 messages as spam yesterday (according to my logs). In the same period it learnt 291 as ham. These figures are reasonably representative of the traffic (on weekdays, anyway) Can anyone explain what happened to the bayes db? It's now steadily auto-learning itself back to normal, but we are going to get many more false negatives today I think. Any information/explanation appreciated. Chris PS I think it's extremely unlikely that there's been a concerted attack/mistake by users using sa-learn the wrong way and re-learning the spam as ham. For one thing, spamassassin is called by exim during the smtp phase, and if the e-mail is marked as spam it's never delivered to anyone. For another thing, there's nobody else around that knows what sa-learn is.
Re: Hotmail on sorbs?!?
On Donnerstag, 22. September 2005 22:24 email builder wrote: How so? I can't believe you don't hear me when I say for the 100th time that services like ours that have a lot of users who expect to communicate with hotmail users cannot use an RBL in the MTA if it lists hotmail. Larry said it already: There are RCVD_IN_SORBS_* rules in 20_dnsbl_tests.cf for each of the various SORBS lists. The ones for RCVD_IN_SORBS_SPAM are commented out. We're also having lots of customers communicating with hotmail.com, didn't get a report of problems for months. Just pick the right rules. If the RCVD_IN_SORBS_SPAM doesn't fit you, don't activate it, it's disabled by default (I guess for a reason...). mfg zmi -- // Michael Monnerie, Ing.BSc --- it-management Michael Monnerie // http://zmi.at Tel: 0660/4156531 Linux 2.6.11 // PGP Key: lynx -source http://zmi.at/zmi2.asc | gpg --import // Fingerprint: EB93 ED8A 1DCD BB6C F952 F7F4 3911 B933 7054 5879 // Keyserver: www.keyserver.net Key-ID: 0x70545879 pgpfea6IcQShf.pgp Description: PGP signature
Re: amavisd-new
Steven, i am looking for a way to modify my subject line so that the spam assassin hits show in the subjectline but since i am useing amavisd-new i think it has to occure in the amavisd.conf file. Unfortunately this is not available off the shelf. The only modification to the Subject header field available is to insert a string like **SPAM**, which is configurable. For other data insertions and Subject modifications you will have to hack the code. All the tools for the job are there, it is just that no config knobs exist for this. Mark
RulesDuJour; lint failes
Hi all,
I'm using spamassassin 3 with rules du jour.
Since a few days, when my rules du jour is runned by cron, spamassassin
won't lint the rules anymore. I've looked into this problem on various
sites, but didn't find a working answer, so I re-installed rules du jour but
still have the same problems. So perhaps someone here knows what to do?
my /etc/rulesdujour/config:
TRUSTED_RULESETS=TRIPWIRE
SA_DIR=/etc/mail/spamassassin
MAIL_ADDRESS=[EMAIL PROTECTED]
SA_RESTART=/etc/init.d/spamassassin restart
(I'm just using one ruleset for testing purposes)
my /etc/mail/spamassassin/local.cf:
required_score 3
report_safe 1
rewrite_header subject {Spam}
bayes_auto_learn 1
bayes_auto_learn_threshold_nonspam 0.1
bayes_auto_learn_threshold_spam 12.0
When running the /usr/local/sbin/rules_du_jour script, the rules are
attempted to lint, which failes. The following is logged:
(zoltar is my machines name)
Installing new ruleset from
/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2
Installing new version...
TripWire has changed on zoltar.
Version line: # Version 1.18 More Typo's fixed.
Attempting to --lint the rules.
No files updated; No restart required.
Rules Du Jour Run Summary:RulesDuJour Run Summary on zoltar:
TripWire has changed on zoltar.
Version line: # Version 1.18 More Typo's fixed.
***WARNING***: spamassassin --lint failed.
Rolling configuration files back, not restarting SpamAssassin.
Rollback command is: mv -f /etc/mail/spamassassin/tripwire.cf
/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2; rm -f
/etc/mail/spamassassin/tripwire.cf;
Lint output: warning: description for CLICK_TO_REMOVE_1 is over 50 chars
warning: description for HTML_IMAGE_RATIO_06 is over 50 chars
warning: description exists for non-existent rule LOSEWEIGHT
...
And then a whole more lot of warnings telling that 'description exists for
non-existent rule ...' and descriptions which are over 50 chars, which I
can't paste here because my mail gets returned because it's marked as spam
:)
It sums up to:
...
lint: 274 issues detected. please rerun with debug enabled for more
information.
Anybody know what this could be?
Cheers,
Thijs
Re: RulesDuJour; lint failes
Did you just move from 2.64 or earlier? It looks like you have some
pre-3.0-only rules files. SOme of these appear to be standard SA rules
files.
Loren
- Original Message -
From: Thijs Koetsier | Exception [EMAIL PROTECTED]
To: users@spamassassin.apache.org
Sent: Friday, September 23, 2005 5:02 AM
Subject: RulesDuJour; lint failes
Hi all,
I'm using spamassassin 3 with rules du jour.
Since a few days, when my rules du jour is runned by cron, spamassassin
won't lint the rules anymore. I've looked into this problem on various
sites, but didn't find a working answer, so I re-installed rules du jour
but
still have the same problems. So perhaps someone here knows what to do?
my /etc/rulesdujour/config:
TRUSTED_RULESETS=TRIPWIRE
SA_DIR=/etc/mail/spamassassin
MAIL_ADDRESS=[EMAIL PROTECTED]
SA_RESTART=/etc/init.d/spamassassin restart
(I'm just using one ruleset for testing purposes)
my /etc/mail/spamassassin/local.cf:
required_score 3
report_safe 1
rewrite_header subject {Spam}
bayes_auto_learn 1
bayes_auto_learn_threshold_nonspam 0.1
bayes_auto_learn_threshold_spam 12.0
When running the /usr/local/sbin/rules_du_jour script, the rules are
attempted to lint, which failes. The following is logged:
(zoltar is my machines name)
Installing new ruleset from
/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2
Installing new version...
TripWire has changed on zoltar.
Version line: # Version 1.18 More Typo's fixed.
Attempting to --lint the rules.
No files updated; No restart required.
Rules Du Jour Run Summary:RulesDuJour Run Summary on zoltar:
TripWire has changed on zoltar.
Version line: # Version 1.18 More Typo's fixed.
***WARNING***: spamassassin --lint failed.
Rolling configuration files back, not restarting SpamAssassin.
Rollback command is: mv -f /etc/mail/spamassassin/tripwire.cf
/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2; rm -f
/etc/mail/spamassassin/tripwire.cf;
Lint output: warning: description for CLICK_TO_REMOVE_1 is over 50 chars
warning: description for HTML_IMAGE_RATIO_06 is over 50 chars
warning: description exists for non-existent rule LOSEWEIGHT
...
And then a whole more lot of warnings telling that 'description exists for
non-existent rule ...' and descriptions which are over 50 chars, which I
can't paste here because my mail gets returned because it's marked as spam
:)
It sums up to:
...
lint: 274 issues detected. please rerun with debug enabled for more
information.
Anybody know what this could be?
Cheers,
Thijs
RE: trusted_networks use
From: NFN Smith [mailto:[EMAIL PROTECTED] Bowie Bailey wrote: X-Spam-Score: 6.87 (**) (required=4) tests=CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE, NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES,REMOVE_SUBJ,RISK_FREE I don't see ALL_TRUSTED, so apparently this email originated outside of your network. Otherwise, there are no tests listed here that would be affected by your trusted_networks settings. It's definitely coming from an external network. From the beginning, I've tried to emphasize that each of the servers in question are hosted in different co-lo facilities, with completely different blocks of IP addresses. We control all the servers, and they're definitely trusted, but they're not local to each other. Yes, I understand that your servers are separated in different IP blocks and in different facilities, but that is irrelevant. When I say that the email is coming from an external network, what I mean is that it is originating from a server that is not in your trusted_networks list. All of the servers that you control should be listed in trusted_networks. This tell SA that it can trust the headers coming from them and trust them not to originate spam. That looks like a faked header. Is your server really called alpha.example.com? Real data redacted for security reasons. I don't have the freedom to be more detailed in a public discussion. Yes, I know it makes troubleshooting more difficult this way. I can understand not wanting to post email addresses, but IP addresses are not private information in most cases. They get published in DNS records and broadcast to anyone the server communicates with. If we're dealing with internal network IPs, then I can understand. It does, however make troubleshooting more difficult. In this case, I don't think we really need to go there yet. At the moment, we are mainly trying to establish how SA is supposed to work. Once we agree on what is supposed to happen, then if there was an email that didn't seem to be scored properly, I would need to see the headers in order to diagnose the scoring. As I said above, this looks like a normal email coming from outside of your network. If it really originated inside your network, then you need to fix your trusted_networks. Beyond that, everything looks normal as far as I can tell from the information provided. As noted, the message definitely originates in a different network. Let me make sure I have the problem definition correct -- We have servers in several co-lo facilities, and each server hosts several domains, each with its own IP address. As noted, the domains and the servers are trusted, but they're in separate networks. The problem that we do have is that when we list our domains via whitelist_from, then incoming mail with forged From: lines that shows one of those domains (typically, the same domain as the addressee) is given a free pass. As noted by Matt Kettler, whitelist_from is very dangerous for exactly that reason. Don't use it. For this, there's no reason to trust the From: line as being valid, because it's so easily forged. However, if the message is coming from known trusted IP addresses, then that's reason to the message a pass, and either have SA give a low score, or not run SA at all. In short, in the question of how the message is handled, we want to trust the server IP address, but assume that the From: line is probably forged. From this discussion, I think I'm trying to do something outside the scope of what SA is designed to do, and the better way of getting there is the suggestion of doing it via MIMEDefang, and bypassing the call to SA altogether if the message is coming from a trusted (but non-local) server. The solution to the problem depends on exactly what you want to accomplish. If you want the email to bypass scanning completely, then that needs to be addressed outside of SA. Once a message is passed to SA, it WILL be scanned -- there is no method to prevent it. If you want to avoid local mail being marked as spam, this can be done in SA with a combination of settings. trusted_networks Every mailserver you control (no matter what network it is on) should be listed here. SA uses this list to determine from the headers when the email entered your sphere of control. Your servers will not be checked for blacklisting and the spam score for the email will be reduced on emails that originate within your control. This setting MUST be set correctly since it affects so many other things in SA. internal_networks This should contain all of the mailservers listed in trusted_networks except those that are expected to receive mail directly from computers on dial-up connections. If none of your mailservers receive mail directly from dial-up connections, you can leave this empty and it will default to the same settings as
RE: RulesDuJour; lint failes
Hi,
No, I did not.
I just re-installed Rules Du Jour and am using Spamassassin 3 on this server
since I installed it.
Cheers,
Thijs
-Oorspronkelijk bericht-
Van: Loren Wilton [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 23 september 2005 15:46
Aan: users@spamassassin.apache.org
Onderwerp: Re: RulesDuJour; lint failes
Did you just move from 2.64 or earlier? It looks like you have some
pre-3.0-only rules files. SOme of these appear to be standard SA
rules files.
Loren
- Original Message -
From: Thijs Koetsier | Exception [EMAIL PROTECTED]
To: users@spamassassin.apache.org
Sent: Friday, September 23, 2005 5:02 AM
Subject: RulesDuJour; lint failes
Hi all,
I'm using spamassassin 3 with rules du jour.
Since a few days, when my rules du jour is runned by cron,
spamassassin
won't lint the rules anymore. I've looked into this problem
on various
sites, but didn't find a working answer, so I re-installed
rules du jour
but
still have the same problems. So perhaps someone here knows
what to do?
my /etc/rulesdujour/config:
TRUSTED_RULESETS=TRIPWIRE
SA_DIR=/etc/mail/spamassassin
MAIL_ADDRESS=[EMAIL PROTECTED]
SA_RESTART=/etc/init.d/spamassassin restart
(I'm just using one ruleset for testing purposes)
my /etc/mail/spamassassin/local.cf:
required_score 3
report_safe 1
rewrite_header subject {Spam}
bayes_auto_learn 1
bayes_auto_learn_threshold_nonspam 0.1
bayes_auto_learn_threshold_spam 12.0
When running the /usr/local/sbin/rules_du_jour script, the rules are
attempted to lint, which failes. The following is logged:
(zoltar is my machines name)
Installing new ruleset from
/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2
Installing new version...
TripWire has changed on zoltar.
Version line: # Version 1.18 More Typo's fixed.
Attempting to --lint the rules.
No files updated; No restart required.
Rules Du Jour Run Summary:RulesDuJour Run Summary on zoltar:
TripWire has changed on zoltar.
Version line: # Version 1.18 More Typo's fixed.
***WARNING***: spamassassin --lint failed.
Rolling configuration files back, not restarting SpamAssassin.
Rollback command is: mv -f /etc/mail/spamassassin/tripwire.cf
/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2; rm -f
/etc/mail/spamassassin/tripwire.cf;
Lint output: warning: description for CLICK_TO_REMOVE_1 is
over 50 chars
warning: description for HTML_IMAGE_RATIO_06 is over 50 chars
warning: description exists for non-existent rule LOSEWEIGHT ...
And then a whole more lot of warnings telling that
'description exists for
non-existent rule ...' and descriptions which are over 50
chars, which I
can't paste here because my mail gets returned because it's
marked as spam
:)
It sums up to:
...
lint: 274 issues detected. please rerun with debug enabled for more
information.
Anybody know what this could be?
Cheers,
Thijs
3.04 to 3.1.0 impressions?
For those who went from 3.0.4 to the latest release candidate, would you say it's a worthy upgrade? Where do you see the largest benefits? Is it overall a good move if you're currently pretty satisfied with 3.0.4? Matt -- Matthew Yette Senior Engineer (NOC/Operations) M.A. Polce Consulting 315-838-1644
Re: 3.04 to 3.1.0 impressions?
On 9/23/05, Matthew Yette [EMAIL PROTECTED] wrote: For those who went from 3.0.4 to the latest release candidate, would you say it's a worthy upgrade? Where do you see the largest benefits? Is it overall a good move if you're currently pretty satisfied with 3.0.4? I've only done this so far on my test machine, but I've seen that a number of new spams are now being tagged correctly.. These were the newer breed of spams which seemed to be slipping by.. So, it seems to be working better here.. I'm planning on rolling it out next week.. Matt -- Matthew Yette Senior Engineer (NOC/Operations) M.A. Polce Consulting 315-838-1644 -- Jason 'XenoPhage' Frisvold [EMAIL PROTECTED]
RE: 3.04 to 3.1.0 impressions?
From: Matthew Yette [mailto:[EMAIL PROTECTED] For those who went from 3.0.4 to the latest release candidate, would you say it's a worthy upgrade? Where do you see the largest benefits? Is it overall a good move if you're currently pretty satisfied with 3.0.4? 3.10 is not just at RC but at full release. I have been using dev builds and each RC for a month or more and love it. It runs smoother and with fewer oddities than 3.04 etc. I have been on 3.10 since a couple of days after the release (it only took that long because the last RC was solid enough itself.) Due diligence but upgrade when you can. -- Herb Martin
Re: FUZZY rules
Found the problem. Should have toubleshoot myself more before posting. Irina = - Original Message - From: Irina [EMAIL PROTECTED] To: users@spamassassin.apache.org Sent: Friday, September 23, 2005 8:41 AM Subject: FUZZY rules Hello all, I can not figure out why I have these errors when running 'spamassassin --lint'. It complains about FUZZY rules: - config: warning: score set for non-existent rule FUZZY_GUARANTEE config: warning: score set for non-existent rule FUZZY_BILLION config: warning: score set for non-existent rule FUZZY_TRAMADOL config: warning: score set for non-existent rule FUZZY_THOUSANDS config: warning: score set for non-existent rule FUZZY_OBLIGATION etc. - When doing grep FUZZY_GUARANTEE /usr/local/share/spamassassin/* it gives --- 25_replace.cf:body FUZZY_GUARANTEE /inter W1post P2(?!guarantee)GUARANTEE/i 25_replace.cf:describe FUZZY_GUARANTEE Attempt to obfuscate words in spam 25_replace.cf:replace_rules FUZZY_GUARANTEE 50_scores.cf:score FUZZY_GUARANTEE 2.880 2.960 3.330 3.658 Is this replace.cf is not included somehow? Thank you for your help. Irina
Re: Oddities since change to 3.1
[EMAIL PROTECTED] wrote: I am getting Sep 21 09:34:20 snout spamd[28958]: mkdir /nonexistent: Permission denied at /usr/local/share/perl/5.8.4/Mail/SpamAssassin.pm line 1467 Sep 21 09:34:20 snout spamd[28958]: locker: safe_lock: cannot create tmp lockfile /nonexistent/.spamassassin/auto-whitelist.lock.snout.codemist.co.uk.28958 for /nonexistent/.spamassassin/auto-whitelist.lock: No such file or directory Sep 21 09:34:20 snout spamd[28958]: Can't call method finish on an undefined value at /usr/local/share/perl/5.8.4/Mail/SpamAssassin/Plugin/AWL.pm line 397. This was installed from source like all previous versions of SA, and this is the first time I have had problems. I tried to look at teh UPGRADE file and it did not seem to make much sense to me Do you pass a -u parameter to spamc or spamd? If not, do you call spamc as root? If so, spamd will scan mail as nobody for safety. Is nobody's home directory set to /nonexistent?
Re: Bayes expiry/oddity
* Chris Lear wrote (09/23/05 10:34): I'm running a reasonably small site-wide spamassassin, and I use a site-side bayes db. Spamassassin runs as the user spamd. I noticed that I got spam last night with no BAYES_XX markup. I looked into it this morning, and discovered that the bayes db only has 47 spam messages in it (nspam from sa-learn --dump magic). It has about 69000 ham. It must have gone from 200 spams at around 11pm last night to 50 this morning, and the only explanation I can think of is that the spam has been expired, but on the other hand this seems odd. Spamassassin learnt 143 messages as spam yesterday (according to my logs). In the same period it learnt 291 as ham. These figures are reasonably representative of the traffic (on weekdays, anyway) Can anyone explain what happened to the bayes db? It's now steadily auto-learning itself back to normal, but we are going to get many more false negatives today I think. Any information/explanation appreciated. None forthcoming, so I'm putting this down to a freak bayes database corruption. sa-learn --dump magic now shows 161 spam and 69310 ham learnt, and I'm letting it sort itself out. In about 3 months I guess it will be back to normal :-). Spamassassin works fairly well without bayes, so I don't mind too much, but I would feel happier if I thought that what happened was understandable. Chris
arrrgh.. debian sarge spamassassin worthless?
so much spam is getting in since I switched to sarge. anyone else have this problem? it looks like the tests are working but stuff that is so obviously spam is getting right through. if i add -D to /etc/default/spamassassin:OPTIONS will the output go to the syslog? -Matt
RE: 3.04 to 3.1.0 impressions?
For those who went from 3.0.4 to the latest release candidate, would you say it's a worthy upgrade? Where do you see the largest benefits? Is it overall a good move if you're currently pretty satisfied with 3.0.4? I can't speak for other platforms, but for Windows users, I'd rate this is a must-have upgrade. The combination of upgrading to ActivePerl 5.8.7 and SA 3.1.0 fixed some serious socket issues with DNS queries. SA 3.0.x used to crash regularly here even in single-threaded mode. Some of the was the way SA handled DNS queries for RBL and URIBL; some of it was Net::DNS; some of it was ActivePerl. I haven't had a crash since prior to 3.1.0 pre1 (i.e., back before it was even at release candidate level), and have enabled parallel_requests now so multiple threads of SA are happening-- have verified it in the logs-- and still no crashes. Kudos to the developers! If you have any stability problems with this on Windows, upgrading ActivePerl, Net::DNS and SA has a very good chance of stabilizing the environment. It did here. Bret
supplying PERL5LIB in Makefile
Hello, in order to fix my Perl module trouble, I tried to supply PERL5LIB in the Makefile. PERL5LIB=/usr/local/share/amavisd-new/i386-linux perl Makefile.PL works fine, now the correct version of Net::DNS is found - but only in the makefile. spamd still contains the wrong use lib, thus resulting in compile errors. Is there any way of giving SA the correct Perl use lib module path? Would manually editing it in spamd help, or are there other files involved? Thanks Florian
Re: arrrgh.. debian sarge spamassassin worthless?
I have been seeing a large increase in spam overall, I wouldn't be so sure if it's anything you caused. Matthew Lenz wrote: so much spam is getting in since I switched to sarge. anyone else have this problem? it looks like the tests are working but stuff that is so obviously spam is getting right through. if i add -D to /etc/default/spamassassin:OPTIONS will the output go to the syslog? -Matt
Re: RulesDuJour; lint failes
Run spamassassin --lint on this server and fix the errors you have and then
once all is running well, go back and try rulesDuJour. You'll get better
results for sure :)
Thijs Koetsier | Exception wrote:
Hi,
No, I did not.
I just re-installed Rules Du Jour and am using Spamassassin 3 on this
server since I installed it.
Cheers,
Thijs
-Oorspronkelijk bericht-
Van: Loren Wilton [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 23 september 2005 15:46
Aan: users@spamassassin.apache.org
Onderwerp: Re: RulesDuJour; lint failes
Did you just move from 2.64 or earlier? It looks like you have some
pre-3.0-only rules files. SOme of these appear to be standard SA
rules files.
Loren
- Original Message -
From: Thijs Koetsier | Exception [EMAIL PROTECTED]
To: users@spamassassin.apache.org
Sent: Friday, September 23, 2005 5:02 AM
Subject: RulesDuJour; lint failes
Hi all,
I'm using spamassassin 3 with rules du jour.
Since a few days, when my rules du jour is runned by cron,
spamassassin
won't lint the rules anymore. I've looked into this problem
on various
sites, but didn't find a working answer, so I re-installed
rules du jour
but
still have the same problems. So perhaps someone here knows
what to do?
my /etc/rulesdujour/config:
TRUSTED_RULESETS=TRIPWIRE
SA_DIR=/etc/mail/spamassassin
MAIL_ADDRESS=[EMAIL PROTECTED]
SA_RESTART=/etc/init.d/spamassassin restart
(I'm just using one ruleset for testing purposes)
my /etc/mail/spamassassin/local.cf:
required_score 3
report_safe 1
rewrite_header subject {Spam}
bayes_auto_learn 1
bayes_auto_learn_threshold_nonspam 0.1
bayes_auto_learn_threshold_spam 12.0
When running the /usr/local/sbin/rules_du_jour script, the rules are
attempted to lint, which failes. The following is logged:
(zoltar is my machines name)
Installing new ruleset from
/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2
Installing new version...
TripWire has changed on zoltar.
Version line: # Version 1.18 More Typo's fixed.
Attempting to --lint the rules.
No files updated; No restart required.
Rules Du Jour Run Summary:RulesDuJour Run Summary on zoltar:
TripWire has changed on zoltar.
Version line: # Version 1.18 More Typo's fixed.
***WARNING***: spamassassin --lint failed.
Rolling configuration files back, not restarting SpamAssassin.
Rollback command is: mv -f /etc/mail/spamassassin/tripwire.cf
/etc/mail/spamassassin/RulesDuJour/99_FVGT_Tripwire.cf.2; rm -f
/etc/mail/spamassassin/tripwire.cf;
Lint output: warning: description for CLICK_TO_REMOVE_1 is
over 50 chars
warning: description for HTML_IMAGE_RATIO_06 is over 50 chars
warning: description exists for non-existent rule LOSEWEIGHT ...
And then a whole more lot of warnings telling that
'description exists for
non-existent rule ...' and descriptions which are over 50
chars, which I
can't paste here because my mail gets returned because it's
marked as spam
:)
It sums up to:
...
lint: 274 issues detected. please rerun with debug enabled for more
information.
Anybody know what this could be?
Cheers,
Thijs
Re: 3.04 to 3.1.0 impressions?
Matthew Yette wrote: For those who went from 3.0.4 to the latest release candidate, would you say it's a worthy upgrade? Where do you see the largest benefits? Is it overall a good move if you're currently pretty satisfied with 3.0.4? Matt I love the new ReplaceTags plugin, I would recommend this upgrade just for the added benefits those rules bring. Plus we'll be releasing a set of replacetags rules next week just for those who run 3.1.
DnsResolver and Received.pm issues?
After upgrading 3.0.4 to 3.1.0, I get this in maillog: Sep 23 14:32:05 MAILER-02 spamd[26236]: spamd: checking message [EMAIL PROTECTED] for qscand:511 Sep 23 14:32:05 MAILER-02 spamd[26236]: Can't call method string on an undefined value at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/DnsResolver.pm line 376, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: Can't call method string on an undefined value at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/DnsResolver.pm line 376, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: Use of uninitialized value in hash element at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/Message/Metadata/Received.p m line 320, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: Use of uninitialized value in hash element at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/Message/Metadata/Received.p m line 321, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: Can't call method string on an undefined value at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/DnsResolver.pm line 376, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: Use of uninitialized value in hash element at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/Message/Metadata/Received.p m line 320, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: Use of uninitialized value in hash element at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/Message/Metadata/Received.p m line 321, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/Message/Metadata/Received.p m line 225, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: Use of uninitialized value in pattern match (m//) at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/Message/Metadata/Received.p m line 227, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: Use of uninitialized value in concatenation (.) or string at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/Message/Metadata/Received.p m line 228, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: Can't call method string on an undefined value at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/DnsResolver.pm line 376, GEN5 line 53. Sep 23 14:32:05 MAILER-02 spamd[26236]: dns: sendto() failed: at /usr/lib/perl5/site_perl/5.8.5/Mail/SpamAssassin/DnsResolver.pm line 320, GEN5 line 53. Sep 23 14:32:06 MAILER-02 last message repeated 22 times So some messages will work alright but some will return ?/? From SA - the ones that generate these messages in maillog. Any idea what's wrong w/ these perl mods and what I can do to fix them? Thanks! Matt -- Matthew Yette Senior Engineer (NOC/Operations) M.A. Polce Consulting 315-838-1644
Re: Oddities since change to 3.1
Indeed nobody have /nonexistent as home directory My problem is that I did not change anything from the 3.0.2 setup and now the system does not work as it did. The .spamassassin file is in /root and always has been. The question is how to make it work again. ==John ffitch
Re: Oddities since change to 3.1
[EMAIL PROTECTED] wrote: Indeed nobody have /nonexistent as home directory My problem is that I did not change anything from the 3.0.2 setup and now the system does not work as it did. The .spamassassin file is in /root and always has been. The question is how to make it work again. That would have been a bug in SA 3.0.2, because you aren't supposed to be able to do that. Spamd should *never* read configfiles from root's homedir. There have been great lengths taken to make sure it won't, but apparently some of that protection failed at some point. This has been an intentional feature since SA 2.31: http://bugzilla.spamassassin.org/show_bug.cgi?id=547 The docs were even updated in 3.0.3 to be updated to specify you can't use root when doing spamd -u: http://bugzilla.spamassassin.org/show_bug.cgi?id=3952 If you're not doing per-user configs, create yourself a spamd user, and pass that to spamd's -u, then use that user for your sa-learning, and housing your user_prefs, etc.
Re: arrrgh.. debian sarge spamassassin worthless?
it makes me wonder if maybe the debian guys messed with the rankings for stuff from the URL block list matches. I'll have an email come through that hits like 3 url block lists ..but gets an ALL_TRUSTED which cancels them out. -Matt On Fri, 2005-09-23 at 14:04 -0400, Fred wrote: I have been seeing a large increase in spam overall, I wouldn't be so sure if it's anything you caused. Matthew Lenz wrote: so much spam is getting in since I switched to sarge. anyone else have this problem? it looks like the tests are working but stuff that is so obviously spam is getting right through. if i add -D to /etc/default/spamassassin:OPTIONS will the output go to the syslog? -Matt
Re: trusted_networks use
Bowie Bailey wrote: It's definitely coming from an external network. Yes, I understand that your servers are separated in different IP blocks and in different facilities, but that is irrelevant. When I say that the email is coming from an external network, what I mean is that it is originating from a server that is not in your trusted_networks list. All of the servers that you control should be listed in trusted_networks. This tell SA that it can trust the headers coming from them and trust them not to originate spam. OK. Now we're on the same page. I had misunderstood the definition of local as the same IP block, rather than the group of trusted servers. I can understand not wanting to post email addresses, but IP addresses are not private information in most cases. I can redo this with live data that shows real data that I'm comfortable with disclosing. See below. As noted by Matt Kettler, whitelist_from is very dangerous for exactly that reason. Don't use it. Makes sense. That's the point of the exercise. Now I just need to get the mechanics working. The solution to the problem depends on exactly what you want to accomplish. If you want the email to bypass scanning completely, then that needs to be addressed outside of SA. Once a message is passed to SA, it WILL be scanned -- there is no method to prevent it. If you want to avoid local mail being marked as spam, this can be done in SA with a combination of settings. For this, I don't need to bypass SA scanning, but it would be an alternate path. trusted_networks internal_networks whitelist_from_rcvd The bottom line is that there is no way to prevent an email from being scanned once it gets to SA, but you can take steps to prevent it from being marked as spam. That's not a problem. The real issue is making sure that we don't trust forged From: lines. Also, SA doesn't care how widely scattered your MXs are as long as it knows who they are. Don't think of it as multiple separate networks containing mailservers, think of it as a single logical network containing all of the mailservers you control. OK. That's exactly where I want to go. From there, I've done more tinkering, but still not getting the results I want. Another try on raw data. Starting with settings in sa-mimedefang.cf: # IP addresses of trusted hosts -- use these instead of whitelisting our domains trusted_networks68.99.120.79 internal_networks whitelist_from_rcvd [EMAIL PROTECTED]lakecmmtao05.coxmail.com I hadn't had a setting for internal_networks, but reading the man definition, it seems worth putting it there with a null definition. From there, I generated a message that was delivered with the following relevant headers: Received: from lakecmmtao05.coxmail.com (lakecmmtao05.coxmail.com [68.99.120.79] ) by pulsar.lfa.com (8.13.1/8.13.1) with ESMTP id j8NJ4Oxs027324 for [EMAIL PROTECTED]; Fri, 23 Sep 2005 12:04:25 -0700 Received: from [192.168.1.100] (really [24.249.175.230]) by lakecmmtao05.coxmail.com (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Fri, 23 Sep 2005 15:04:19 -0400 Message-ID: [EMAIL PROTECTED] Date: Fri, 23 Sep 2005 12:03:32 -0700 From: NFN Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [SPAM: 7.737] Spam test #6 X-Spam-Status: Yes X-Spam-Score: 7.737 (***) (required=4) tests=BLANK_LINES_70_80,CLICK_BELOW,E XCUSE_3,FREE_CONSULTATION,MAILTO_TO_REMOVE,NO_OBLIGATION,ONE_TIME_MAILING,REMOVE _IN_QUOTES,REMOVE_SUBJ,RISK_FREE X-Scanned-By: MIMEDefang 2.44 Thus, I sent a message through a coxmail.com server, showing the sacbeemail.com address in the From: line (a combination I want to trust, at least for testing purposes), and addressed to [EMAIL PROTECTED] The target machine is lfa.com. Relevant log entries show: Sep 23 12:04:25 pulsar sendmail[27324]: j8NJ4Oxs027324: from=[EMAIL PROTECTED], size=1607, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], proto=ESMTP, daemon=MTA, relay=lakecmmtao05.coxmail.com [68.99.120.79] Sep 23 12:04:26 pulsar mimedefang.pl[27269]: MDLOG,j8NJ4Oxs027324,spam,7.737,68.99.120.79,[EMAIL PROTECTED],[EMAIL PROTECTED],Spam test #6 Sep 23 12:04:26 pulsar sendmail[27324]: j8NJ4Oxs027324: Milter change: header Subject: from Spam test #6 to [SPAM: 7.737] Spam test #6 Sep 23 12:04:26 pulsar sendmail[27324]: j8NJ4Oxs027324: Milter add: header: X-Scanned-By: MIMEDefang 2.44 Sep 23 12:04:26 pulsar sendmail[27328]: j8NJ4Oxs027324: to=[EMAIL PROTECTED], delay=00:00:01, xdelay=00:00:00, mailer=local, pri=33885, dsn=2.0.0, stat=Sent Thus, in the results that I'm getting, I don't have something quite right in the combination of definitions between trusted_networks and whitelist_from_rcvd. From what I've figured out so far, I seem to be close, but I'm missing something small. Thanks for your patience as I figure
subject rewrite
Hello all, I am wondering if anyone knows how to get the score of the SPAM in the subject line with the rewrite. Right now I rewrite the subject line with [SPAM] at the beginning but it would be helpful to see the score in the same place. Also I attach the original e-mail and I use spamassassin 3.04 on redhat 9 with spamd/spamc.. Robert Peace he would say instead of goodbyepeace my brother.
Re: trusted_networks use
Bowie Bailey wrote: whitelist_from_rcvd You can use this instead of whitelist_from. It requires a bit more setup, but it is immune to the forgery problems of whitelist_from. Use this to list each valid domainname/mailserver combination. Note that this requires a correct internal_networks configuration to work properly. For a less effort solution, you can use whitelist_from_spf in SA 3.1 if you've got SPF set up in SpamAssassin and the domain in question publishes SPF records. Daryl
Re: trusted_networks use
NFN Smith wrote: Thus, in the results that I'm getting, I don't have something quite right in the combination of definitions between trusted_networks and whitelist_from_rcvd. From what I've figured out so far, I seem to be close, but I'm missing something small. Did you remember to restart your milter?
Re: subject rewrite
Robert Swan wrote: Hello all, I am wondering if anyone knows how to get the score of the SPAM in the subject line with the rewrite. Right now I rewrite the subject line with [SPAM] at the beginning but it would be helpful to see the score in the same place. Also I attach the original e-mail and I use spamassassin 3.04 on redhat 9 with spamd/spamc.. Robert Peace he would say instead of goodbyepeace my brother. RTFM for rewrite_header, via the html doc pages, the answer is in the first paragraph HTH -- Thanks, JamesDR smime.p7s Description: S/MIME Cryptographic Signature
Re: arrrgh.. debian sarge spamassassin worthless?
Matthew Lenz wrote: it makes me wonder if maybe the debian guys messed with the rankings for stuff from the URL block list matches. I'll have an email come through that hits like 3 url block lists ..but gets an ALL_TRUSTED which cancels them out. You may want to consider properly setting your trusted_networks.
Re: SA-3.1.0 permission problems
Przemek wrote: Hi, I have spamassassin-3.1.0 runing as daemon from slackware-rc-script included with sa. My sa work with qmail-scanner. Before updating form 3.0.4 everything was good, but now on 3.1.0 after reciving mail i see this in logs: Looks like SA is being invoked as root, which causes it to fall back to nobody.. Nobody doesn't have permissions to it's home dir (and should not) so it fails. That should have been a problem for you in 3.0.4, but you might not have noticed , as SA may not have complained loudly. Perhaps you should create a dedicated user to use instead of root.
About qmail and SA
Hi all, I posted yday about SA and how it does not seem to work at all for me... but I got no replies. :( spamassassin --lint seems to show no errors but I am not sure if qmail and qmail-scanner and SA are all communicating with each other. I am flooded with Spam and do not know what to do. Please help. :( Sent from the SpamAssassin - Users forum at Nabble.com.
Prefork efficiency
Hi, I see a lot of forking ever since I switched to 3.1. Is there a way to tell the maximum and the average number of forks reached? If so, would it be more efficient in terms of speed to switch back to the old method or the difference is really negligible up to a certain number of forks? Thnx, Lefteris
RE: trusted_networks use
From: NFN Smith [mailto:[EMAIL PROTECTED] From there, I've done more tinkering, but still not getting the results I want. Another try on raw data. Starting with settings in sa-mimedefang.cf: # IP addresses of trusted hosts -- use these instead of whitelisting our domains trusted_networks68.99.120.79 internal_networks whitelist_from_rcvd [EMAIL PROTECTED] lakecmmtao05.coxmail.com I hadn't had a setting for internal_networks, but reading the man definition, it seems worth putting it there with a null definition. Hmm... I'm not sure what effect that internal_networks line will have. If you don't want to explicitly set it, just leave it out and let it default to the trusted_networks setting. From there, I generated a message that was delivered with the following relevant headers: Received: from lakecmmtao05.coxmail.com (lakecmmtao05.coxmail.com [68.99.120.79] ) by pulsar.lfa.com (8.13.1/8.13.1) with ESMTP id j8NJ4Oxs027324 for [EMAIL PROTECTED]; Fri, 23 Sep 2005 12:04:25 -0700 Received: from [192.168.1.100] (really [24.249.175.230]) by lakecmmtao05.coxmail.com (InterMail vM.6.01.05.02 201-2131-123-102-20050715) with ESMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Fri, 23 Sep 2005 15:04:19 -0400 Message-ID: [EMAIL PROTECTED] Date: Fri, 23 Sep 2005 12:03:32 -0700 From: NFN Smith [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [SPAM: 7.737] Spam test #6 X-Spam-Status: Yes X-Spam-Score: 7.737 (***) (required=4) tests=BLANK_LINES_70_80,CLICK_BELOW,EXCUSE_3,FREE_CONSULTATION, MAILTO_TO_REMOVE,NO_OBLIGATION,ONE_TIME_MAILING,REMOVE_IN_QUOTES, REMOVE_SUBJ,RISK_FREE X-Scanned-By: MIMEDefang 2.44 Thus, I sent a message through a coxmail.com server, showing the sacbeemail.com address in the From: line (a combination I want to trust, at least for testing purposes), and addressed to [EMAIL PROTECTED] The target machine is lfa.com. Ok, so here is what I see as far as the mail path: - Sent from 24.249.175.230 ... untrusted - Received by 68.99.120.79 ... trusted - Received by pulsar.lfa.com ... untrusted (unless SA defaults the local machine) Relevant log entries show: Sep 23 12:04:25 pulsar sendmail[27324]: j8NJ4Oxs027324: from=[EMAIL PROTECTED], size=1607, class=0, nrcpts=1, msgid=[EMAIL PROTECTED], proto=ESMTP, daemon=MTA, relay=lakecmmtao05.coxmail.com [68.99.120.79] Sep 23 12:04:26 pulsar mimedefang.pl[27269]: MDLOG,j8NJ4Oxs027324,spam,7.737,68.99.120.79,[EMAIL PROTECTED] beemail.com,[EMAIL PROTECTED],Spam test #6 Sep 23 12:04:26 pulsar sendmail[27324]: j8NJ4Oxs027324: Milter change: header Subject: from Spam test #6 to [SPAM: 7.737] Spam test #6 Sep 23 12:04:26 pulsar sendmail[27324]: j8NJ4Oxs027324: Milter add: header: X-Scanned-By: MIMEDefang 2.44 Sep 23 12:04:26 pulsar sendmail[27328]: j8NJ4Oxs027324: to=[EMAIL PROTECTED], delay=00:00:01, xdelay=00:00:00, mailer=local, pri=33885, dsn=2.0.0, stat=Sent Thus, in the results that I'm getting, I don't have something quite right in the combination of definitions between trusted_networks and whitelist_from_rcvd. From what I've figured out so far, I seem to be close, but I'm missing something small. Ok...I just re-read the man page entry for whitelist_from_rcvd. Now I think I follow what is happening. The IP that is checked is the one that sent mail to your internal network (as defined by internal_networks). So this is what happened: lakecmmtao05.coxmail.com is part of your internal network, so the check was pushed back to the previous server, 24.249.175.230, which translates to wsip-24-249-175-230.ph.ph.cox.net and doesn't match the whitelist_from_rcvd line. What you probably want to do is this: internal_networks 64.65.180.91 trusted_networks 64.65.180.91 trusted_networks 68.99.120.79 So that pulsar.lfa.com is internal and trusted, while lakecmmtao05.coxmail.com is trusted, but not internal. That way, you can use lakecmmtao05 in the whitelist_from_rcvd commands. Whitelist_from_rcvd can only check domains outside of your internal_networks. So for what you want, only the local machine is internal. All others are simply trusted. Try it that way and see what happens. Can anyone else who is more knowledgeable about how internal_networks and trusted_networks interact comment on this? I think this will work fine, but I want to make sure there aren't any side effects that I'm not considering. Bowie
Re: arrrgh.. debian sarge spamassassin worthless?
its _not_ set.. shouldn't that mean there are no trusted networks?.. unless the debian package is patched some how. -Matt p.s. actually i didn't think ALL_TRUSTED had to do with that setting.. i though maybe it only showed up if it didn't pass through any of the rbl relays. - Original Message - From: Daryl C. W. O'Shea [EMAIL PROTECTED] To: users@spamassassin.apache.org Sent: Friday, September 23, 2005 2:54 PM Subject: Re: arrrgh.. debian sarge spamassassin worthless? Matthew Lenz wrote: it makes me wonder if maybe the debian guys messed with the rankings for stuff from the URL block list matches. I'll have an email come through that hits like 3 url block lists ..but gets an ALL_TRUSTED which cancels them out. You may want to consider properly setting your trusted_networks.
Re: trusted_networks use
Bowie Bailey wrote: Ok, so here is what I see as far as the mail path: - Sent from 24.249.175.230 ... untrusted - Received by 68.99.120.79 ... trusted - Received by pulsar.lfa.com ... untrusted (unless SA defaults the local machine) If pulsar.lfa.com is untrusted, all headers will be untrusted. After all, an untrusted box is assumed to be able to forge headers, thus it could have forged the 68.99.120.79 header. Since you can't prove it's not forged by pulsar, you can't trust it. You really do HAVE to trust all your own mail relays. Anything else is just broken.
Re: subject rewrite
On Fri, Sep 23, 2005 at 03:43:23PM -0400, Robert Swan wrote: Hello all, I am wondering if anyone knows how to get the score of the SPAM in the subject line with the rewrite. Right now I rewrite the subject line with [SPAM] at the beginning but it would be helpful to see the score in the same place. Also I attach the original e-mail and I use spamassassin 3.04 on redhat 9 with spamd/spamc.. rewrite_header subject *SPAM* (score=_SCORE_/_REQD_) Works for me with 3.0.1. -- /-\ | Michael Barnes [EMAIL PROTECTED] | | UNIX Systems Administrator | | College of William and Mary | | Phone: (757) 879-3930 (cell)| \-/
Re: arrrgh.. debian sarge spamassassin worthless?
Matthew Lenz wrote: its _not_ set.. shouldn't that mean there are no trusted networks?.. unless the debian package is patched some how. It must be set. If it's not SpamAssassin has to guess at which networks/hosts are yours. p.s. actually i didn't think ALL_TRUSTED had to do with that setting.. i though maybe it only showed up if it didn't pass through any of the rbl relays. ALL_TRUSTED fires when SA thinks all of the relays are truested (all are in trusted_networks). trusted_neworks also affects some DNSBL lookups, whitelist_from_rcvd, SPF checks, whitelist_from_spf, and insert any other network related (even network related local tests) feature here. Daryl
RE: trusted_networks use
From: Matt Kettler [mailto:[EMAIL PROTECTED] Bowie Bailey wrote: Ok, so here is what I see as far as the mail path: - Sent from 24.249.175.230 ... untrusted - Received by 68.99.120.79 ... trusted - Received by pulsar.lfa.com ... untrusted (unless SA defaults the local machine) If pulsar.lfa.com is untrusted, all headers will be untrusted. After all, an untrusted box is assumed to be able to forge headers, thus it could have forged the 68.99.120.79 header. Since you can't prove it's not forged by pulsar, you can't trust it. True, of course. I was just reading each IP on it's own. The first header (reading from the top) from an untrusted IP address and all of the headers below it will not be trusted. My only question there was whether SA will implicitly trust the machine it is running on. After all, if you can't trust yourself, who can you trust? :) Bowie
Re: arrrgh.. debian sarge spamassassin worthless?
any way to tell what it considers to be a trusted_network? we have 5 private segments and all those servers use postfix with a 'relayhost' which resolves to the private ip address of our smtp server. all of our users also use this smtp server for sending mail from their desktops. they all nat through a single ip on one of said networks above. there is a 1:1 nat that maps a public ip to that priviate ip for our smtp server. so do i just put all 5 segements plus the public ip address we use for our mailserver? this trusted_networking documentation is really difficult to understand. :( - Original Message - From: Daryl C. W. O'Shea [EMAIL PROTECTED] To: Matthew Lenz [EMAIL PROTECTED] Cc: users@spamassassin.apache.org Sent: Friday, September 23, 2005 4:03 PM Subject: Re: arrrgh.. debian sarge spamassassin worthless? Matthew Lenz wrote: its _not_ set.. shouldn't that mean there are no trusted networks?.. unless the debian package is patched some how. It must be set. If it's not SpamAssassin has to guess at which networks/hosts are yours. p.s. actually i didn't think ALL_TRUSTED had to do with that setting.. i though maybe it only showed up if it didn't pass through any of the rbl relays. ALL_TRUSTED fires when SA thinks all of the relays are truested (all are in trusted_networks). trusted_neworks also affects some DNSBL lookups, whitelist_from_rcvd, SPF checks, whitelist_from_spf, and insert any other network related (even network related local tests) feature here. Daryl
Re: arrrgh.. debian sarge spamassassin worthless?
Matthew Lenz wrote: any way to tell what it considers to be a trusted_network? we have 5 You can run a message through spamassassin -D to find out. In a nated environment it's going to guess wrong though, guaranteed. private segments and all those servers use postfix with a 'relayhost' which resolves to the private ip address of our smtp server. all of our users also use this smtp server for sending mail from their desktops. they all nat through a single ip on one of said networks above. there is a 1:1 nat that maps a public ip to that priviate ip for our smtp server. so do i just put all 5 segements plus the public ip address we use for our mailserver? Yes, all your private addresses or CIDR blocks and your public IP(s). Daryl
Re: subject rewrite
On Fri, 23 Sep 2005, Michael Barnes wrote: I prefer: rewrite_header Subject [SPAM-Score-_HITS_] == Chris Candreva -- [EMAIL PROTECTED] -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/
Re: trusted_networks use
Matt Kettler wrote: Bowie Bailey wrote: Ok, so here is what I see as far as the mail path: - Sent from 24.249.175.230 ... untrusted - Received by 68.99.120.79 ... trusted - Received by pulsar.lfa.com ... untrusted (unless SA defaults the local machine) If pulsar.lfa.com is untrusted, all headers will be untrusted. After all, an untrusted box is assumed to be able to forge headers, thus it could have forged the 68.99.120.79 header. Since you can't prove it's not forged by pulsar, you can't trust it. You really do HAVE to trust all your own mail relays. Anything else is just broken. Agreed. OK, I've expanded my settings, but I'm still not making any progress. trusted_networks64.65.180.91 trusted_networks10.10.10.141 trusted_networks68.99.120.79 trusted_networks24.249.175.230 internal_networks 64.65.180.91 internal_networks 10.10.10.141 whitelist_from_rcvd [EMAIL PROTECTED]pulsar.lfa.com whitelist_from_rcvd [EMAIL PROTECTED]lakecmmtao05.coxmail.com whitelist_from_rcvd [EMAIL PROTECTED]wsip-24-249-175-230.ph.ph.cox.net - pulsar.lfa.com has a public address of 64.65.180.91, and its internal IP address is 10.10.10.91 - lacecmmtao05.coxmail.com is 68.99.120.79 - 24.249.175.230 (wsip-24-249-175-230.ph.ph.cox.net) is the network that I'm sending my mail from. What else am I missing? Smith
Re: trusted_networks use
Bowie Bailey wrote: My only question there was whether SA will implicitly trust the machine it is running on. After all, if you can't trust yourself, who can you trust? :) If you explicitly set trusted_networks, then no, it won't SA will only trust the hosts you tell it. If you don't have a trusted_networks delcared, then the auto-trust algorithm will trust the machine it runs on, and possibly others.
Re: arrrgh.. debian sarge spamassassin worthless?
ok. i think i got it. what parts of the headers does spamassassin look at for trusted_networks? my guess is that if there are any untrusted ip's mentioned in the received: headers it marks it as untrusted? what about my pop-before-smtp users? they'll be relaying through the public ip sending emails to one another on that same machine. how does it know that isn't a direct MX spam? - Original Message - From: Daryl C. W. O'Shea [EMAIL PROTECTED] To: Matthew Lenz [EMAIL PROTECTED] Cc: users@spamassassin.apache.org Sent: Friday, September 23, 2005 4:21 PM Subject: Re: arrrgh.. debian sarge spamassassin worthless? Matthew Lenz wrote: any way to tell what it considers to be a trusted_network? we have 5 You can run a message through spamassassin -D to find out. In a nated environment it's going to guess wrong though, guaranteed. private segments and all those servers use postfix with a 'relayhost' which resolves to the private ip address of our smtp server. all of our users also use this smtp server for sending mail from their desktops. they all nat through a single ip on one of said networks above. there is a 1:1 nat that maps a public ip to that priviate ip for our smtp server. so do i just put all 5 segements plus the public ip address we use for our mailserver? Yes, all your private addresses or CIDR blocks and your public IP(s). Daryl
Re: arrrgh.. debian sarge spamassassin worthless?
Matthew Lenz wrote: ok. i think i got it. what parts of the headers does spamassassin look at for trusted_networks? my guess is that if there are any untrusted ip's mentioned in the received: headers it marks it as untrusted? Yeah, it trusts each received header starting from the top until it finds an IP that's not in the list of trusted_networks. what about my pop-before-smtp users? they'll be relaying through the public ip sending emails to one another on that same machine. how does it know that isn't a direct MX spam? Some questions first... 1. do you control the IPs that your dial-up users are connecting from 2. does the smtp smarthost that the dial-up users use have the same IP as the smtp server that is passing the mail to SA or is it different? 3. can you obtain enough pain medication to get them all to convert to auth'd SMTP connections? Daryl
Re: arrrgh.. debian sarge spamassassin worthless?
Matthew Lenz wrote: ok. i think i got it. what parts of the headers does spamassassin look at for trusted_networks? my guess is that if there are any untrusted ip's mentioned in the received: headers it marks it as untrusted? Yeah, it trusts each received header starting from the top until it finds an IP that's not in the list of trusted_networks. what about my pop-before-smtp users? they'll be relaying through the public ip sending emails to one another on that same machine. how does it know that isn't a direct MX spam? Some questions first... 1. do you control the IPs that your dial-up users are connecting from no.. they all connect from various isp's. 2. does the smtp smarthost that the dial-up users use have the same IP as the smtp server that is passing the mail to SA or is it different? they connect to the public ip address which is a 1:1 nat to the private ip that postfix/SA run on. I just tried it myself. I sent an email from myself to myself and SA noticed that i connected directly to the smtp server from an ip in DUL's. RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL it wasn't enough to classify it as spam but still kinda worry's me. previously just had people send work email via their isp smtp servers. but that doesn't play well with SPF does it? (for future consideration.. i don't have any spf stuff enabled that I know of) 3. can you obtain enough pain medication to get them all to convert to auth'd SMTP connections? heh I thought about implementing it .. maybe i still can at some point. Daryl
Re: arrrgh.. debian sarge spamassassin worthless?
On Fri, Sep 23, 2005 at 02:08:40PM -0500, Matthew Lenz wrote: it makes me wonder if maybe the debian guys messed with the rankings for stuff from the URL block list matches. I'll have an email come through that hits like 3 url block lists ..but gets an ALL_TRUSTED which cancels them out. The Debian packages do not change any scores or modify the code in any meaningful way. The only substantial change is the addition of rules that should prevent e-mails automatically generated by your system from being classified as spam. On a related note, I have not gotten a chance to package 3.1.0 yet. :-( It wouldn't take me long to do it, but I don't have the time to test it adequately... :-( -- Duncan Findlay signature.asc Description: Digital signature
Re: arrrgh.. debian sarge spamassassin worthless?
sorry for the top post.. OE sucks. thanks for the packages Duncan :) i noticed that you don't use your people.debian.org location for packages (atleast that I saw) .. you could also stick em there I'm sure people would test em if it was easy to track them using apt. When they are in experimental or unstable it makes it more difficult unless you wanna do weird pinning stuff I like the way that backports.org does it giving each package its own repository. works really well :) -Matt On Fri, Sep 23, 2005 at 02:08:40PM -0500, Matthew Lenz wrote: it makes me wonder if maybe the debian guys messed with the rankings for stuff from the URL block list matches. I'll have an email come through that hits like 3 url block lists ..but gets an ALL_TRUSTED which cancels them out. The Debian packages do not change any scores or modify the code in any meaningful way. The only substantial change is the addition of rules that should prevent e-mails automatically generated by your system from being classified as spam. On a related note, I have not gotten a chance to package 3.1.0 yet. :-( It wouldn't take me long to do it, but I don't have the time to test it adequately... :-( -- Duncan Findlay
Re: arrrgh.. debian sarge spamassassin worthless?
Matthew Lenz wrote: 1. do you control the IPs that your dial-up users are connecting from no.. they all connect from various isp's. 3. can you obtain enough pain medication to get them all to convert to auth'd SMTP connections? heh I thought about implementing it .. maybe i still can at some point. Well, you're in the no-fun group then. If you could do smtp auth SA would automatically extend the trust boundary for you -- problem solved. Your easiest option is to abandon SPF and tell your users to use their own ISP's smarthost. Another option is to find a way (that will vary depending on how you call SpamAssassin) to bypass SA checks for the POP before SMTP users. Finally, you could modify the AccessDB plugin in 3.1 to extend trust rather than penalize mail from hosts found with bad flags in the DB. If I get sufficiently bored and find enough food I may look into this sometime. Daryl
Re: arrrgh.. debian sarge spamassassin worthless?
can SA read berkley db hash:'s like postfix does? something like trusted_networks = ... 123.123.121. ... hash:/var/lib/pop-before-smtp/hosts if so that would be very cool cuz just as that hash allows people to temporarily use postfix as a relay (it removes the entries from the has after 30minutes of activity) it could also temporary add them as trusted_network ips. that would be really cool. - Original Message - From: Daryl C. W. O'Shea [EMAIL PROTECTED] To: Matthew Lenz [EMAIL PROTECTED] Cc: users@spamassassin.apache.org Sent: Friday, September 23, 2005 5:27 PM Subject: Re: arrrgh.. debian sarge spamassassin worthless? Matthew Lenz wrote: 1. do you control the IPs that your dial-up users are connecting from no.. they all connect from various isp's. 3. can you obtain enough pain medication to get them all to convert to auth'd SMTP connections? heh I thought about implementing it .. maybe i still can at some point. Well, you're in the no-fun group then. If you could do smtp auth SA would automatically extend the trust boundary for you -- problem solved. Your easiest option is to abandon SPF and tell your users to use their own ISP's smarthost. Another option is to find a way (that will vary depending on how you call SpamAssassin) to bypass SA checks for the POP before SMTP users. Finally, you could modify the AccessDB plugin in 3.1 to extend trust rather than penalize mail from hosts found with bad flags in the DB. If I get sufficiently bored and find enough food I may look into this sometime. Daryl
Re: arrrgh.. debian sarge spamassassin worthless?
Matthew Lenz wrote: can SA read berkley db hash:'s like postfix does? something like trusted_networks = ... 123.123.121. ... hash:/var/lib/pop-before-smtp/hosts if so that would be very cool cuz just as that hash allows people to temporarily use postfix as a relay (it removes the entries from the has after 30minutes of activity) it could also temporary add them as trusted_network ips. that would be really cool. Nope, nothing at the present (except for the AccessDB plugin that looks for IPs to reject). Daryl
Re: SA-3.1.0 permission problems
On Fri, 23 Sep 2005 15:57:36 -0400 Matt Kettler [EMAIL PROTECTED] wrote: Looks like SA is being invoked as root, which causes it to fall back to nobody.. Nobody doesn't have permissions to it's home dir (and should not) so it fails. That should have been a problem for you in 3.0.4, but you might not have noticed , as SA may not have complained loudly. Wenn i use 3.0.4 .spamassassin dir is always recreated (if not exist) without any errors. (in home dir) Perhaps you should create a dedicahd user to use instead of root. I try but i dont know how to made a user allow to change /home/* Wenn i set spam:x:0:0:,,,:/var/spamd:/bin/bash and run spamd with -u spam, spamd want start. option -u cant by use with notexisting user or root Please help. -- Przemysław Ciemniewski mailto:[EMAIL PROTECTED] GG:155998 JID: [EMAIL PROTECTED]
RE: 3.04 to 3.1.0 impressions?
--On Friday, September 23, 2005 9:54 AM -0500 Herb Martin [EMAIL PROTECTED] wrote: I have been using dev builds and each RC for a month or more and love it. It runs smoother and with fewer oddities than 3.04 etc. I have been on 3.10 since a couple of days after the release (it only took that long because the last RC was solid enough itself.) Same story here. The first rc caught a lot of spam that had been leaking through 3.0.4. The later rc's and release are just refinements to me (ie. they closed bugs that were affecting others but that I wasn't experiencing).
Re: Hotmail on sorbs?!?
On Donnerstag, 22. September 2005 22:24 email builder wrote: How so? I can't believe you don't hear me when I say for the 100th time that services like ours that have a lot of users who expect to communicate with hotmail users cannot use an RBL in the MTA if it lists hotmail. Larry said it already: There are RCVD_IN_SORBS_* rules in 20_dnsbl_tests.cf for each of the various SORBS lists. The ones for RCVD_IN_SORBS_SPAM are commented out. We're also having lots of customers communicating with hotmail.com, didn't get a report of problems for months. Just pick the right rules. If the RCVD_IN_SORBS_SPAM doesn't fit you, don't activate it, it's disabled by default (I guess for a reason...). No. Please understand that there is a difference between using SORBS in the MTA (ala Postfix's smtpd_recipient_restrictions) where a listing equates to an immediate rejection and using SORBS in SA for scoring. You are referring to the latter. I have said many times that the thread was about the former. I don't think anyone disagrees with using SORBS in SA scoring. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
