Discuss

discuss@lists.surbl.org

1 participants
1867 discussions

Death By DNS
by Rob McEwen 27 Jul '04

27 Jul '04

RE: Death By DNS I never mentioned this before, but these extra lookups can be like firecrackers going off. I do three types of DNS lookups: (1) basic RBL checking of sending server's IP address using sbl-xbl.spamhaus.org (2) content RBL lookup for domains and IP addresses using multi.surbl.org (3) content RBL lookup for IP addresses (not domains) using sbl-xbl.spamhaus.org (BTW - Does anyone have a "feel" for sbl-xbl.spamhaus.org and false positives. I wonder sometimes if that particular RBL list is too strict?) Anyway, the second and third of these two levels can sometimes cause several DNS lookups per one singe message. Eventually, I noticed that my server was slowing down. Web sites were being served slower. Also, my mail server software is NOT know for robustness and several articles on their user's group site mention that it falters if the DNS server is slow or has any problems. So I thought... could there be a connection? My next "project" was to then improve the DNS caching on my Windows 2000 server. I tried to tweak the client DNS caching, but with little success/options. Next, I looked into installing the full Windows 2000 DNS service... but I'm not a network engineer and the settings seemed strange and the instructions confusing. Finally, I found the answer. I found a 3rd party "caching" DNS server which works great for my purposes. It has a lot of good features, like saving cached DNS data between reboots. You can find this software here: http://ntcanuck.com/ After installing it, I notice that web sites on my server which were taking about 2 extra seconds longer to load than they used to take started flashing across the screen instantaneously. I know that my conclusions about this are not scientific, but its hard to argue with results. Rob McEwen

2 1

Syntax error on line 1 near eval:
by David Groce 27 Jul '04

27 Jul '04

I am cross posting, but I need to find an answer quick. I finally removed my rpm installation of Spamassassin and installed via CPAN, which allowed me to install the SpamCopURI plugin as well. When I run spamassssin --lint, I get an error on the SpamCopURI.cf Specifically: Failed to compile URI SpamAssassin tests, skipping: (syntax error at /etc/mail/spamassassin/spamcop_uri.cf, rule SPAMCOP_URI_RBL, line 1, near "eval:" Any ideas why this might be? I've also had problems with SpamAssassin itself since installed via CPAN, where I see these errors: Scalar found where operator expected at (eval 17) line 686, near "} $self" (Missing operator before $self?) Failed to run header SpamAssassin tests, skipping some: syntax error at (eval 17) line 686, near "} $self" Any guesses there? Perhaps related to the SpamCopURI plugin? David Groce CCNA Network Server Analyst/Coordinator North Kitsap School District

2 5

RE: Syntax error on line 1 near eval:
by Randal, Phil 27 Jul '04

27 Jul '04

Martin wrote: > David Groce wrote: > >> I am cross posting, but I need to find an answer quick. I finally >> removed my rpm installation of Spamassassin and installed via CPAN, >> which allowed me to install the SpamCopURI plugin as well. When I run >> spamassssin --lint, I get an error on the SpamCopURI.cf Specifically: >> >> Failed to compile URI SpamAssassin tests, skipping: >> (syntax error at > /etc/mail/spamassassin/spamcop_uri.cf, rule >> SPAMCOP_URI_RBL, line 1, near "eval:" > > I had the same problem when i installed SpamCopUri for the first time. > Check for linewraps in spamcop_uri.cf. That solved my problem. > > / Martin When I patched our spamassassin 2.63 (on Fedora Core 1) to include SpamCopURI it worked, but spamassassin --lint was failing. In the end I tracked it down to spamassassin stuff being in the vendor_perl directory relating to an older release of perl. Copying the appropriate .pm files from SpamCopUri to the appropriate Mail/Spamassassin directory in the /usr/lib/perl5 tree solved that problem. So I'd have a dig in /usr/lib/perl5 looking for Mail/Spamassassin and making sure the SpamCopURI modules are in there. Phil ---- Phil Randal Network Engineer Herefordshire Council Hereford, UK

1 0

RE: SPAM: Phishing attempt?
by Chris Santerre 27 Jul '04

27 Jul '04

>-----Original Message----- >From: kriston(a)MOUSE-WORKS.COM [mailto:kriston@MOUSE-WORKS.COM] >Sent: Monday, July 26, 2004 3:29 AM >To: SPAM-L(a)PEACH.EASE.LSOFT.COM >Subject: Re: SPAM: Phishing attempt? > > >On 26 Jul 2004 at 1:07, David Smith <dbsmith(a)ATBBS.DYNDNS.ORG> wrote: > >> 01o.com belongs to Britemoon, Inc. A quick websearch brings up >> mentions of Britemoon as a spammer, which is why I'm wondering >> if Qwest might not have hired them for this. Is it common for a >> known spammer to go into the phishing business? > >According to here, http://www.britemoon.com/about/index3.html, >Qwest is >one of their clients. Britemoon probably does their email >marketing. I >came across the same thing with Consumer Reports when I confirmed that >they were using a DoubleClick subsidiary to do their "email >marketing", >aka spamming. > NANAS has lots of hits for this guy. Joe Lucas. He send UBE/UCE on behalf of large businesses like Days Inn, Fedex, Qwest, ect....... But it is spam, as they buy lists to send to and there is no opt-in. Not even close to double opt-in :) --Chris

2 1

Make Test Failure
by Ray Dzek 26 Jul '04

26 Jul '04

Is this failure significant? Or can I proceed with the make install? Redhat 8 on 1.4Ghz Celeron with 768MB of RAM. Perl 5.8. Latest Net::DNS installed prior to install of SURBL. Thanks in advance. PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/blacklist........ok t/dnsrbl...........ok t/mailto...........ok t/open_redirect....NOK 3# Failed test (t/open_redirect.t at line 35) t/open_redirect....NOK 4# Failed test (t/open_redirect.t at line 37) t/open_redirect....ok 5/8# Looks like you failed 2 tests of 8. t/open_redirect....dubious Test returned status 2 (wstat 512, 0x200) DIED. FAILED tests 3-4 Failed 2/8 tests, 75.00% okay t/spamcopuri.......ok t/whitelist........ok Failed Test Stat Wstat Total Fail Failed List of Failed ---------------------------------------------------------------------------- --- t/open_redirect.t 2 512 8 2 25.00% 3-4 Failed 1/6 test scripts, 83.33% okay. 2/30 subtests failed, 93.33% okay. make: *** [test_dynamic] Error 29 Ray Dzek Network Operations Supervisor Specialized Bicycle Components

2 1

RE: [SURBL-Discuss] Make Test Failure
by Chris Santerre 26 Jul '04

26 Jul '04

>-----Original Message----- >From: Ray Dzek [mailto:rdzek@specialized.com] >Sent: Monday, July 26, 2004 1:47 PM >To: discuss(a)lists.surbl.org >Subject: [SURBL-Discuss] Make Test Failure > > >Is this failure significant? Or can I proceed with the make install? > Proceed! Known issue, and no big deal. Go ahead with your bad self, and make install. --Chris (Feeling much better now, lookout! (: )

2 1

RE: [SURBL-Discuss] {Spam?} RE: someone found a way to beat SURBL
by Chris Santerre 26 Jul '04

26 Jul '04

>-----Original Message----- >From: Rob McEwen [mailto:webmaster@powerviewsystems.com] >Sent: Sunday, July 25, 2004 10:11 PM >To: 'Jeff Chan'; 'SURBL Discussion list' >Subject: [SURBL-Discuss] {Spam?} RE: someone found a way to beat SURBL >Importance: High > > >RE: someone found a way to beat SURBL > >They take the following url: > >http://google.info/url?q= > >and follow this by their own URL HTMLEncoded > >The trick is for the parser to be able to find and decode this >HTMLEncoded >url when gathering URLs for checking against SURBL. > >I purposely did not send this to the discussion group because >I didn't want >this to be "out there" for spammers to know about. However, it >would be good >for the various "parser writers" for the various software >programs that work >with SURBL to be aware of this. > >Rob McEwen >PowerView Systems >rob(a)PowerViewSystems.com >(478) 475-9032 > Standard redirect technique, which there is a SARE rule for and SA 3.0 will nail this no problem. --Chris

1 0

Jeff's whitelists
by William Stearns 26 Jul '04

26 Jul '04

Good evening, Jeff, I wanted to check in with you about some domains removed because of your whitelists. There are a few in particular I wanted to cover. gevalia.com and joingevalia.com: gevalia does a _lot_ of spam. nutrisystem.com: again, a lot of recent spam, just done with a bulk marketing firm as a front. spamarrest.com: spammers themselves Any sense on the above? Cheers, - Bill --------------------------------------------------------------------------- "Hackers do not feel that leisure time is automatically any more meaningful than work time. The desirability of both depends on how they are realized. From the point of a view of a meaningful life, the entire work/leisure duality must be abandoned. As long as we are living our work or our leisure, we are not even truly living. Meaning cannot be found in work or leisure but has to arise out of the nature of the activity itself. Out of passion. Social value. Creativity." -- Andrew Leonard <aleonard(a)salon.com> http://salon.com/tech/col/leon/2001/02/05/hacker_ethic/index2.html -------------------------------------------------------------------------- William Stearns (wstearns(a)pobox.com). Mason, Buildkernel, freedups, p0f, rsync-backup, ssh-keyinstall, dns-check, more at: http://www.stearns.org --------------------------------------------------------------------------

11 36

RFC: Drop multi.surbl.org rbldnsd TTL?
by Jeff Chan 26 Jul '04

26 Jul '04

Should we decrease the TTL on the rbldnsd version of multi.surbl.org? For some background on the issue, rbldnsd does not support setting individual TTLs per record for dnset type zones, so we could not set individual TTLs on the rbldnsd records in multi.surbl.org, so the TTL for all records in the rbldnsd version of multi are the default for the entire file which is currently 28800 (8 hours). Obviously that's quite a bit longer than the 90 minutes now used on ws or the 10 minutes for sc, so some multi/rbldnsd records may be longer-lived than their BIND versions. This is in conflict with the fact that we can and do set individual TTLs per record in the *BIND* version of multi. So a particular record in BIND multi versus rbldnsd multi may very likely have different TTLs, which is an asymmetry and somewhat inelegant. In other words a server that uses BIND may not give the same TTL for a given entry that an rbldnsd one would. One solution to this would be to drop the default rbldnsd TTL for multi to something short like 10 minutes to force them all to expire quickly. Does anyone have any thoughts about this? Would this result in a lot more DNS traffic in general? I could probably read the RFCs or source code, but does anyone know if DNS implementations cache negative hits to the default TTL. In other words if a new record gets added to a list, do caching name servers (that negatively cached it before, i.e., got queried and said "I don't have that") get the new record immediately or only after some TTL expires. Jeff C. -- Jeff Chan mailto:jeffc@surbl.org http://www.surbl.org/

2 2

[SURBL-Discuss] {Spam?} FOLLOW-UP: someone found a way to beat SURBL
by Rob McEwen 26 Jul '04

26 Jul '04

FOLLOW-UP: someone found a way to beat SURBL Jeff, I said... "I purposely did not send this to the discussion group" I think I goofed and DID accidentally send that last message to the discussion group. Sorry about that. Perhaps you could intercept it and/or remove it. Sorry for the trouble. Thanks, Rob McEwen PowerView Systems rob(a)PowerViewSystems.com (478) 475-9032

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss