AWL
Hi all, I'm having a little trouble with my Spamassassin v3 and the autowhitelist. I'm trying to remove an email address from the list, but it is not working. If anyone has any ideas, please let me know. Here is what I'm doing: #cat auto-whitelist | strings | grep jason [EMAIL PROTECTED]|ip=142.179 [EMAIL PROTECTED]|ip=none|totscore [EMAIL PROTECTED]|ip=none I see the [EMAIL PROTECTED] address in here and when I send email, sure enough it gets points due to AWL. So I try to remove it via: # spamassassin [EMAIL PROTECTED] When I check the auto-whitelist, it doesn't appear to have removed. Any ideas? Thanks Jason
Upgrading to 3.0
Apologies for asking this if the answer is obvious, but I couldn't see it anywhere in the wiki we currently use 2.64 What are the reasons for upgrading to 3.0? TIA R --- This email from dns has been validated by dnsMSS Managed Email Security and is free from all known viruses. For further information contact [EMAIL PROTECTED]
Re: Upgrading to 3.0
Certainly better spam catching if you aren't using addon rules. Probably better spam catching if you are. Gives you a chance to tell your boss you need to upgrade all the email servers to 3GHz/4GB, and thus you need a pay raise! Version is supported. Basically, 2.64 is now old and dead, and won't be getting any new bug fixes. After a while we will stop adding new SARE rules for 2.64, because it will be too much work to maintain them. At the moment I personally consider it a tossup as to using 2.64 or 3.0.2 (and I'm still running 2.64) but that will change with time. Probably you should plan on being on 3.x within the next 4 months or so, would be my recommendation. Loren
Question about URIDNSBL
Good day. I've been having some problems with URIDNSBL plugin for Spam Assassin. One of blocked mail came from emailframer.com . After investigating issue this came up: host -t ns emailframer.com emailframer.com name server ns1.barak.net.il. emailframer.com name server ns.barak.net.il. host -t a ns.barak.net.il ns.barak.net.il has address 212.150.48.169 And this brough me to: http://www.spamhaus.org/SBL/sbl.lasso?query=SBL22121 The problem is - barak.net.il is one of the MAJOR Israel's ISPs, and since MANY hosts have NS record matching it, this SBL record block ALL sites hosted on it. To solve this problem (temporary ofcourse) i've disabled NS lookups in the plugin. What I wanted to know - is this an expected behaviour? If so - how to handle this situation? Best regards, Eli Yukelzon
Re: Question about URIDNSBL
On Tuesday, February 8, 2005, 2:58:32 AM, Eli Yukelzon wrote: http://www.spamhaus.org/SBL/sbl.lasso?query=SBL22121 The problem is - barak.net.il is one of the MAJOR Israel's ISPs, and since MANY hosts have NS record matching it, this SBL record block ALL sites hosted on it. Please complain to Barak that their customer walla.com is sending spam. The problem is not really with SpamHaus but that Barak apparently continues to allow walla.com to be mentioned in thousands of reported spam (and probably many times that unreported). SpamHaus is simply noting that fact. Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Re: Question about URIDNSBL
On Tuesday, February 8, 2005, 5:08:32 AM, Jeff Chan wrote: Please complain to Barak that their customer walla.com is sending spam. The problem is not really with SpamHaus but that Barak apparently continues to allow walla.com to be mentioned in thousands of reported spam (and probably many times that unreported). SpamHaus is simply noting that fact. For approximately 6000 examples, see: http://groups-beta.google.com/group/news.admin.net-abuse.sightings/search?group=news.admin.net-abuse.sightingsq=walla.comqt_g=1searchnow=Search+this+group to search walla.com on Usenet newsgroup news.admin.net-abuse.sightings Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
Tracking Rule Hits
Is there a way to log the number of times a specific rule has hit within spamassassin. Ideally I'd like to see how often a rule hits, and the average score of the messages that it hit on, but anything along those lines would help At the minute the best idea I have come up with is to use an unseen router from within exim to make a copy of the message and call an external script to write the appropriate info to a file/database Any more 'simple' way to do this would be an improvement. TIA Richard --- This email from dns has been validated by dnsMSS Managed Email Security and is free from all known viruses. For further information contact [EMAIL PROTECTED]
RE: Tracking Rule Hits
I believe you could do this using the information that SA puts in syslog now. It lists each rule hit for a spam as well as the score. --Benjamin Story, CCNA CCDAClient Server Technical Analystwww.dotfoods.comIT Helpdesk x2312 From: Gray, Richard [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 7:50 AMTo: users@spamassassin.apache.orgSubject: Tracking Rule Hits Is there a way to log the number of times a specific rule has hit within spamassassin. Ideally I'd like to see how often a rule hits, and the average score of the messages that it hit on, but anything along those lines would help At the minute the best idea I have come up with is to use an unseen router from within exim to make a copy of the message and call an external script to write the appropriate info to a file/database Any more 'simple' way to do this would be an improvement. TIA Richard---This email from dns has been validated by dnsMSS Managed Email Security and is free from all known viruses.For further information contact [EMAIL PROTECTED]
RE: Tracking Rule Hits
Hrm, this may be a reason to upgrade to 3.0 then From: Ben Story [mailto:[EMAIL PROTECTED] Sent: 08 February 2005 13:55To: Gray, Richard; users@spamassassin.apache.orgSubject: RE: Tracking Rule Hits I believe you could do this using the information that SA puts in syslog now. It lists each rule hit for a spam as well as the score. --Benjamin Story, CCNA CCDAClient Server Technical Analystwww.dotfoods.comIT Helpdesk x2312 From: Gray, Richard [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 7:50 AMTo: users@spamassassin.apache.orgSubject: Tracking Rule Hits Is there a way to log the number of times a specific rule has hit within spamassassin. Ideally I'd like to see how often a rule hits, and the average score of the messages that it hit on, but anything along those lines would help At the minute the best idea I have come up with is to use an unseen router from within exim to make a copy of the message and call an external script to write the appropriate info to a file/database Any more 'simple' way to do this would be an improvement. TIA Richard---This email from dns has been validated by dnsMSS Managed Email Security and is free from all known viruses.For further information contact [EMAIL PROTECTED] --- This email from dns has been validated by dnsMSS Managed Email Security and is free from all known viruses. For further information contact [EMAIL PROTECTED]
Re: SPF troubles with users@spamassassin....list
On Tue, Feb 08, 2005 at 07:32:44AM +0100, Philipp Snizek, seaan.net ag wrote: mx.seaan.net is approved for belfin.ch, so that mail should have been accepted. What should I do? Well, I did wait a while but I just got back NDRs. Could you please investigate that? From a quick check, belfin.ch has multiple SPF records, which basically confuses the receiver: $ host -t txt belfin.ch belfin.ch text v=spf1 mx:mx.seaan.net -all belfin.ch text v=spf1 a:mx.seaan.net -all There's only supposed to be 1 record, but there are 2. Since there are no MX RRs for mx.seaan.net, the message fails. I think you want the single: v=spf1 a:mx.seaan.net mx:mx.seaan.net -all -- Randomly Generated Tagline: Fry: I must be a robot. Why else would human women refuse to date me? Leela: Oh, lots of reasons. pgp1CYxywzUZC.pgp Description: PGP signature
RE: disabling ALL_TRUSTED
From: Arvinn Løkkebakken [mailto:[EMAIL PROTECTED]
jdow wrote:
Do not disable it. Fix the cause.
It's time to hit the wiki and learn how.
{^_^}
I hit the wiki and found this patch:
http://bugzilla.spamassassin.org/attachment.cgi?id=2508
Is it the fix you were thinking about?
I doubt that was what he was referring to. You just need to
configure your trust path so that ALL_TRUSTED will know what to
trust. Add a trusted_networks entry in your local.cf for each of
your mailservers (or one for each of your networks) and that should
fix your problem.
For details see the manpage for Mail::SpamAssassin::Conf.
http://spamassassin.apache.org/full/3.0.x/dist/doc/Mail_SpamAssassin_Conf.ht
ml
Bowie
Re: detecting brute-force spams
On Tue, 8 Feb 2005, Rich Puhek wrote: From: Rich Puhek [EMAIL PROTECTED] To: Dan Mahoney, System Admin [EMAIL PROTECTED] Cc: users@spamassassin.apache.org Date: Tue, 08 Feb 2005 10:29:57 -0600 Subject: Re: detecting brute-force spams Dan Mahoney, System Admin wrote: Hey all, I host about 500 domains, and every once in a while I see something where a domain gets hammered for a bunch of non-existent users (in my setup, this results in all the emails going to the same place). Is there a custom rule that can be kicked in to detect multiple recipients of the same email? (snip) I haven't tried the custom rule approach, but I've found increasing success with non SA methods. Yes it's well worth looking at other methods. For example: http://www.iks-jena.de/mitarb/lutz/usenet/teergrube.en.html I don't use the above, but have set up something similar using exim. Sites I catch running dictionary attacks are restricted to a single connection to my mail servers. And are subject to progressively larger delays for every bad address they attempt to use. It does my heart good to see log lines similar to: 2005-02-07 19:45:03 H=(smtp.com) [217.158.171.56] I=[138.38.32.23]:25 F=[EMAIL PROTECTED] temporarily rejected RCPT [EMAIL PROTECTED]: 217.158.171.56 bad recipients 20, delay 30720 You'd think they'd notice the looong delays between RCPT TO commands being temporarily rejected. ... I did switch one of the MX machines to postfix recently. Postfix includes the ability to verify addresses prior to accepting mail, so dictionary attacks can be identified right away. That really cuts down on the quantity of mail sitting in the queue. You can do much the same with exim, depending on how you configure it. That's how I managed to implement the automatic tarpit described above. The OpenBSD operating system even comes with its own tarpitting daemon. It's called spamd, which can cause some confusion. From the man page: spamd is a fake sendmail(8)-like daemon which rejects false mail. If the pf(4) packet filter is configured to redirect port 25 (SMTP) to this dae- mon, it will attempt to waste the time and resources of the spam sender. -- Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK [EMAIL PROTECTED] Phone: +44 1225 386101
Re: disabling ALL_TRUSTED
Arvinn Løkkebakken wrote:
Bowie Bailey wrote:
From: Arvinn Løkkebakken [mailto:[EMAIL PROTECTED]
jdow wrote:
Do not disable it. Fix the cause.
It's time to hit the wiki and learn how.
{^_^}
I hit the wiki and found this patch:
http://bugzilla.spamassassin.org/attachment.cgi?id=2508
Is it the fix you were thinking about?
I doubt that was what he was referring to. You just need to
configure your trust path so that ALL_TRUSTED will know what to
trust. Add a trusted_networks entry in your local.cf for each of
your mailservers (or one for each of your networks) and that should
fix your problem.
For details see the manpage for Mail::SpamAssassin::Conf.
http://spamassassin.apache.org/full/3.0.x/dist/doc/Mail_SpamAssassin_Conf.ht
ml
Bowie
No, that's not correct. Trusted_networks is not a mandatory setting.
ALL_TRUSTED shall not be triggered by messages with Received headers
with hosts that doesn't exist in trusted_networks and friends. It's the
other way around. ALL_TRUSTED only kicks in when all Received headers
only contains hosts that are_defined in trusted_networks and/or friends.
You probably didn't read what I posted carefully enough.
The problem is that ALL_TRUSTED some times get triggered when it
shouldn't, i.e. it gets triggered even when one or more of the Received
headers contains a foreign host that is not in trusted_networks,
internal_networks or in a network near by, because it failed to parse
the actual header. The wiki article (bug 3949) I found describes this
situation exactly as it appears to me. It seems to me that this bug made
it to 3.0.2 even though the wiki article is dated early in November.
The article may be dated early november but the bug itself is still open
and being worked on which is why it still exists in 3.0.2. I imagine it
will be resolved shortly after they get some issues worked out. (From
reading the bug report).
-Jim
Re: AWL
On Tue, Feb 08, 2005 at 11:46:33AM -0700, Jason Bennett wrote: Any other help would be greatly appreciated. Do you by chance have a sitewide auto-whitelist setup? If so, are you sure that you are reading the correct database with check_whitelist? Run with -D and see if that gives you any other clues. Michael pgphAmwQArPE0.pgp Description: PGP signature
RE: AWL
Actually, I just figured it out. The database for my autowhitelist was not in root's home directory. I didn't realize the --remove-from-whitelist option was trying to remove it from a .spamassassin/auto-whitelist from the current user's home directory. I had to change to the user I actually run as and it removed fine. Is there a spamassassin command line option to specify a whitelist database file when I use the --remove... option? Thanks for the help - it clued me on the problem. Jason -Original Message- From: Michael Parker [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 08, 2005 11:49 AM To: Jason Bennett Cc: users@spamassassin.apache.org Subject: Re: AWL On Tue, Feb 08, 2005 at 11:46:33AM -0700, Jason Bennett wrote: Any other help would be greatly appreciated. Do you by chance have a sitewide auto-whitelist setup? If so, are you sure that you are reading the correct database with check_whitelist? Run with -D and see if that gives you any other clues. Michael
bayes db version error
Hi I'm seeing a lot of messages about and version error in the bayes db in my log file: spamd[6562]: bayes: bayes db version 0 is not able to be used, aborting! at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/BayesStore/DBM.pm line 160. I'm using SA 3.0.2. The output of sa-learn show a bayes db version 3. sa-learn --dump magic | grep version 0.000 0 3 0 non-token data: bayes db version This is correct? The reported error it's about version 0. I have read trough the list that this problem is caused by the update of the spamassassin version. I start with the SA version 2.55 that was carried default with the distro. Then upgrade to 3.0.1 or 3.0.0, so 3.0.1 and now 3.0.2. Maybe soon 3.0.3? ;) There is a way to correct this problem? I was thinking in delete the old db, but I'm not very sure where to look. I not use the 2.55 version of SA, it was installed with the distro and I upgrade immediately after install. I looked at /root/.spamassassin for old files but found nothing. Where else this old db could be?? Could this be affecting the spam filtering? BR, Matías.
How SpamAssassin Works ? How to improve Spam Detection
Hi all, I'm new to this mailling lists and to SpamAssassin too. In the past mounths, i have built severals smtp gatewas using the followings : - Postfix 2.13 - Amavisd-new (The lastest Stable Version) - Clamav (0.80) - Mail::SpamAssassin (Lastest Version) Every works great, no crash, memory and cpu consuming stable !!! Everyone over Internet says that SpamAssassin is great product to fight Spam? The result on my smtp gateways does not shown the same result. So i'm considering my configuration is uncomplete !! i'm trying to improve spam detection and i have some questions : (Silly question but i cannot answer it) Do Mail::SpamAssassin need further version of SpamAssassin (Core Distribution) to work ? Do i need to install SpamAssassin Core Distribution on my System ? My conclusion is yes ?? In order to improve SpamAssassin, i 've put CustomRules from SpamAssassin Web Site in /etc/mail/spamassassin/local.cf ?? Is it correct I think yes but confirmation is welcome ? With this things, i can fight complete my configuration and fight the spam !!! Best Regards, Farid
Re: AWL
On Tue, Feb 08, 2005 at 11:55:38AM -0700, Jason Bennett wrote: I had to change to the user I actually run as and it removed fine. Is there a spamassassin command line option to specify a whitelist database file when I use the --remove... option? Check out auto_whitelist_path in perldoc Mail::SpamAssassin::Conf, mode the file mode if used in mixed user environment. Michael pgp2bPQF2Fh27.pgp Description: PGP signature
Re: Incredibly slow SA checks
Is clamd running? Is clamav.conf set up to scan via a tcp socket? If neither of those are happening, then you may be experiencing an amavis timeout while it tries to communicate with clamd. RO To: users@spamassassin.apache.org Sent: Tuesday, February 08, 2005 11:23 AM Subject: Incredibly slow SA checks What process takes place during the Calling SA checks routine? I have amavis-new and spamassassin 3.02 running, with SA configured to use SQL. I cranked up the amavis log_level to 5 and watched the logs. They show a message coming in at what I guess to be acceptable speed until just after the ClamAV check. Right after the ClamAV check I see the Calling SA checks message, then nothing for 20 to 40 seconds, then the next log message. How can I find out what is taking so long? - Gary
Re: Incredibly slow SA checks
ClamAV is running and the amavis log_level=5 setting shows it scanning very very fast. It is whatever takes place next that is boggin things down. - Gary Richard Ozer wrote: Is clamd running? Is clamav.conf set up to scan via a tcp socket? If neither of those are happening, then you may be experiencing an amavis timeout while it tries to communicate with clamd. RO To: users@spamassassin.apache.org Sent: Tuesday, February 08, 2005 11:23 AM Subject: Incredibly slow SA checks What process takes place during the Calling SA checks routine? I have amavis-new and spamassassin 3.02 running, with SA configured to use SQL. I cranked up the amavis log_level to 5 and watched the logs. They show a message coming in at what I guess to be acceptable speed until just after the ClamAV check. Right after the ClamAV check I see the Calling SA checks message, then nothing for 20 to 40 seconds, then the next log message. How can I find out what is taking so long? - Gary
custom URIDNSBL rules
Title: Message
Hi SA
Users,
I have a question
for anyone who may have added their own custom URIDNSBL
lookups.
I have set up
RBLDNSD (successfully as far as I can see) to support both IPs and
URIs.
A command line DNS
call returns the expected results, but SA 3.0.0and URIDNSBL do not 'see'
that the queried URI A record is being returned from my local RBLDNSD zone. Is
there anything that I am missing that would help SA and URIDNSBL to pick up on
the fact that my local RBLDNSD zone has that URI listed?
I've added the
custom rule to run a URIDNSBL check on my localRBLDNSD
server:
# custom
URIBLurirhssub URIBL_HOMES
auth2.homes.com. A
2header
URIBL_HOMES
eval:check_uridnsbl('URIBL_HOMES')describe
URIBL_HOMES Contains an URL in the Homes.com URI
blocklisttflags
URIBL_HOMES
netscore
URIBL_HOMES 1 1
1 1
I can see that SA is
calling my local RBLDNSD server at auth2.homes.com" from SA's DEBUG
output:
debug: plugin:
Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x898ffe4) implements
'check_tick'debug: URIDNSBL: query for broadcastemail.us took 1 seconds to
look up (auth2.homes.com.:broadcastemail.us)"debug: URIDNSBL: domain
"broadcastemail.us" listed (URIBL_AB_SURBL): 127.0.0.102debug: URIDNSBL:
domain "broadcastemail.us" listed (URIBL_SC_SURBL): 127.0.0.102debug:
URIDNSBL: domain "broadcastemail.us" listed (URIBL_WS_SURBL):
127.0.0.102debug: URIDNSBL: query for broadcastemail.us took 1 seconds to
look up (multi.surbl.org.:broadcastemail.us)debug: URIDNSBL: queries
completed: 3 started: 2debug: URIDNSBL: queries active: at Tue
Feb 8 14:49:15 2005
I have the URI
"broadcastemail.us" entered into the RBLDNSD zone. On the command line, the
command: " dig @auth2.homes.com broadcastemail.us.auth2.homes.com A ",
returns the
expected A record:
;
DiG 9.2.1 @auth2.homes.com broadcastemail.us.auth2.homes.com
A;; global options: printcmd;; Got answer:;;
-HEADER- opcode: QUERY, status: NOERROR, id: 13923;; flags:
qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0;;
QUESTION SECTION:;broadcastemail.us.auth2.homes.com. IN
A;; ANSWER SECTION:broadcastemail.us.auth2.homes.com. 2100 IN
A 127.0.0.2;; Query time: 0 msec;; SERVER:
199.44.153.104#53(auth2.homes.com);; WHEN: Tue Feb 8 14:44:43
2005;; MSG SIZE rcvd: 67
Thanks in advance,Shane
Metler
Re: bayes db version error
On Tue, Feb 08, 2005 at 04:37:50PM -0300, Matias Lopez Bergero wrote: I'm seeing a lot of messages about and version error in the bayes db in my log file: spamd[6562]: bayes: bayes db version 0 is not able to be used, aborting! at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/BayesStore/DBM.pm line 160. I'm assuming you're running sitewide bayes (or at least running as a single user) and on a somewhat busy server. That error message is a pretty good indication that SA couldn't get a lock on the bayes db files. It's actually just a warning, not an error, and it may or may not have actually aborted. You'll see this on a setup that is getting a good amount of traffic and using shared/sitewide bayes db files. Several things you can try: 1) If you db files aren't on an NFS filesystem switch your lock_method to flock (the default is nfssafe). If your shared db files are on an NFS filesystem then consider moving them off and switch your lock_method. 2) Throttle the calls to spamd to reduce lock contention. 3) Switch to SQL based bayes which won't (well shouldn't) have that issue. Could this be affecting the spam filtering? In theory, things should filter just fine, you just won't get BAYES results. If you're seeing something different then it's probably a bug. Michael pgpnPbqbJ0aOH.pgp Description: PGP signature
RE: disabling ALL_TRUSTED
From: Arvinn Løkkebakken [mailto:[EMAIL PROTECTED]
Bowie Bailey wrote:
From: Arvinn Løkkebakken [mailto:[EMAIL PROTECTED]
jdow wrote:
Do not disable it. Fix the cause.
It's time to hit the wiki and learn how.
{^_^}
I hit the wiki and found this patch:
http://bugzilla.spamassassin.org/attachment.cgi?id=2508
Is it the fix you were thinking about?
I doubt that was what he was referring to. You just need to
configure your trust path so that ALL_TRUSTED will know what to
trust. Add a trusted_networks entry in your local.cf for each of
your mailservers (or one for each of your networks) and that should
fix your problem.
For details see the manpage for Mail::SpamAssassin::Conf.
http://spamassassin.apache.org/full/3.0.x/dist/doc/Mail_SpamAssassin_Conf.h
tml
No, that's not correct. Trusted_networks is not a mandatory
setting. ALL_TRUSTED shall not be triggered by messages with
Received headers with hosts that doesn't exist in
trusted_networks and friends. It's the other way around.
ALL_TRUSTED only kicks in when all Received headers only contains
hosts that are_defined in trusted_networks and/or friends.
Right, but if trusted_networks is not defined, Courier assumes that
most recent mailserver with a public address is your gateway
mailserver. If your actual gateway server has a NAT address,
Courier will start trusting every mailserver that sends you mail.
It's not a mandatory setting, but as many times as I've seen this
question on the list, it probably should be mandatory.
You probably didn't read what I posted carefully enough. The
problem is that ALL_TRUSTED some times get triggered when it
shouldn't, i.e. it gets triggered even when one or more of the
Received headers contains a foreign host that is not in
trusted_networks, internal_networks or in a network near by,
because it failed to parse the actual header. The wiki article
(bug 3949) I found describes this situation exactly as it appears
to me. It seems to me that this bug made it to 3.0.2 even though
the wiki article is dated early in November.
You're right. I lost track of your original post and assumed you
were having the same problem most everyone else seems to have with
the ALL_TRUSTED rule. Sorry about the confusion.
Bowie
Re: bayes db version error
Michael Parker wrote: On Tue, Feb 08, 2005 at 04:37:50PM -0300, Matias Lopez Bergero wrote: I'm seeing a lot of messages about and version error in the bayes db in my log file: spamd[6562]: bayes: bayes db version 0 is not able to be used, aborting! at /usr/lib/perl5/site_perl/5.8.0/Mail/SpamAssassin/BayesStore/DBM.pm line 160. I'm assuming you're running sitewide bayes (or at least running as a single user) and on a somewhat busy server. Yes, I forgot to say that. I'm running a sitewide install with about 6 incoming messages per day. That error message is a pretty good indication that SA couldn't get a lock on the bayes db files. It's actually just a warning, not an error, and it may or may not have actually aborted. You'll see this on a setup that is getting a good amount of traffic and using shared/sitewide bayes db files. Several things you can try: 1) If you db files aren't on an NFS filesystem switch your lock_method to flock (the default is nfssafe). If your shared db files are on an NFS filesystem then consider moving them off and switch your lock_method. Done. 2) Throttle the calls to spamd to reduce lock contention. Sorry to ask this again, but I'm not native English speaker :-P Did you mean to increase the number of spamd children processes, like spamd -m x? I have currently set spamd -m 10. 3) Switch to SQL based bayes which won't (well shouldn't) have that issue. That's an interesting idea. I'm going to keep that in mind :) Thanks a lot Michael BR, Matías.
Apache mail list archives
Does anyone know the email address of the correct person to report problems with the Apache mailing list archives? The mailing list archives have been sick for over a week. Fortunately the MARC archives have come back to life. I tried sending a report to [EMAIL PROTECTED] some 3 days ago, but nothing has happened. I am subscribed to the users and dev mailing lists, but I find it easier to follow the discussions on a mailing list archive. Tom schulz Applied Dynamics Intl. [EMAIL PROTECTED]
Re: Side-warning about the new proxy zombies...
On Tuesday 08 February 2005 2:14 pm, Kenneth Porter wrote: --On Tuesday, February 08, 2005 11:14 AM -0700 Brian Godette [EMAIL PROTECTED] wrote: care must be taken to have the expiry times reasonable or the iptables rule lists becomes much too large and eventually chews up all available CPU. Have you seen the ipset stuff on the netfilter-devel list? This is a new set of modules that works with sets of addresses. It should allow you to have a much larger rejection list. The rejection list can be pretty huge as it is, however since the script doesn't aggregate IP addresses there is a possibility of it becoming excessively large (8 figures or more) if addresses stay in the list for very long periods of time (months) before being expired. That's completely theoretical since I doubt there's 10's of millions of zombie proxies/open relays out there, but still expiration times that long are IMO excessive.
Re: custom URIDNSBL rules
At 02:56 PM 2/8/2005, Shane Metler wrote: debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x898ffe4) implements 'check_tick' debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up (auth2.homes.com.:broadcastemail.us) debug: URIDNSBL: domain broadcastemail.us listed (URIBL_AB_SURBL): 127.0.0.102 debug: URIDNSBL: domain broadcastemail.us listed (URIBL_SC_SURBL): 127.0.0.102 debug: URIDNSBL: domain broadcastemail.us listed (URIBL_WS_SURBL): 127.0.0.102 debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up (multi.surbl.org.:broadcastemail.us) debug: URIDNSBL: queries completed: 3 started: 2 debug: URIDNSBL: queries active: at Tue Feb 8 14:49:15 2005 I have the URI broadcastemail.us entered into the RBLDNSD zone. On the command line, the command: dig @auth2.homes.com broadcastemail.us.auth2.homes.com A , returns the expected A record: What happens if you try that dig statement WITHOUT the @auth2.homes.com to force the query to a particular name server? i.e.: dig broadcastemail.us.auth2.homes.com Remember, SA is just going to do a general resolve. It's not going to force the queried name server to be auth2.homes.com. It's just going to query that domain using your normal resolv.conf servers...
Re: custom URIDNSBL rules
On Tuesday, February 8, 2005, 3:37:05 PM, Matt Kettler wrote: At 02:56 PM 2/8/2005, Shane Metler wrote: debug: plugin: Mail::SpamAssassin::Plugin::URIDNSBL=HASH(0x898ffe4) implements 'check_tick' debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up (auth2.homes.com.:broadcastemail.us) debug: URIDNSBL: domain broadcastemail.us listed (URIBL_AB_SURBL): 127.0.0.102 debug: URIDNSBL: domain broadcastemail.us listed (URIBL_SC_SURBL): 127.0.0.102 debug: URIDNSBL: domain broadcastemail.us listed (URIBL_WS_SURBL): 127.0.0.102 debug: URIDNSBL: query for broadcastemail.us took 1 seconds to look up (multi.surbl.org.:broadcastemail.us) debug: URIDNSBL: queries completed: 3 started: 2 debug: URIDNSBL: queries active: at Tue Feb 8 14:49:15 2005 I have the URI broadcastemail.us entered into the RBLDNSD zone. On the command line, the command: dig @auth2.homes.com broadcastemail.us.auth2.homes.com A , returns the expected A record: What happens if you try that dig statement WITHOUT the @auth2.homes.com to force the query to a particular name server? i.e.: dig broadcastemail.us.auth2.homes.com Remember, SA is just going to do a general resolve. It's not going to force the queried name server to be auth2.homes.com. It's just going to query that domain using your normal resolv.conf servers... Exactly. The problem is that dig @auth2.homes.com forces the queries to go to a specific server, presumably the name of your rbldnsd server. SA is going to use whatever resolver the system it's on is configured to use. What you should do is set up forwarding for the auth2.homes.com custom zone (and any other rbldnsd zones locally served) from your BIND server to your rbldnsd server. See for examples: http://njabl.org/rsync.html http://www.surbl.org/rbldnsd-howto.html http://www.surbl.org/rbldnsd-bind-freebsd.html Jeff C. -- Jeff Chan mailto:[EMAIL PROTECTED] http://www.surbl.org/
