I'll believe it when I see it. Will you post a log message showing DENIED_RBLMATCH with this address? Perhaps that would shed some light on
your trouble. # qmlog -lc 165.21.21.188 smtp should find where this happened in your log. smtp]# grep "DENIED" * |grep 165.21.21.188 @400000004b14ebc31b052aec.s:@400000004b1370d9356f6ba4 spamdyke[21904]: DENIED_RBL_MATCH from: [email protected] to: [email protected] origin_ip: 165.21.21.188 origin_rdns: lisa.clientdomain.com auth: (unknown) > 165.21.21.188 is not listed in the XBL If you were using the stock spamdyke settings, it's possible that the address was listed at bl.spamcop.net at the time. I've used zen.spamhaus.org and bl.spamcop.net for quite some time, and have seen very few false positives. When there is one, it's simple to whitelist either the domain, rDNS, or IP address. This should only need to be done while the sending server's admin takes measures to become delisted. No I am using only ]# cat /var/qmail/control/blacklists -r sbl.spamhaus.org Were they trying to use your QMT server to send email to an external domain, or were they trying to send from an external server to your QMT server? I'm not clear about which you're talking about. No idea about their mail server’s, ‘sorry to confuse , if I use spamdyke config, the fake mails from external and internal are getting blocked’ but I will end up in seeing multiple DENIALs > sorry to club the other query i made here in list. in smtp/current i > used to get DENIED_RBLMATCH. It's pretty normal to see many of these. It shouldn't be showing up for IP addresses that aren't listed though. I've never heard of spamdyke generating this message in error, even if DNS is broken. if it is blocking valid spam mails I will be the happiest in world, but vendors keep complaining that their mails are bouncing back with spamhaus url, when I grep their domain and check their ip in spamhaus spamhaus.org/zen/index.lasso , it shows this ip is not listed. now at current scenario with your help I want to achieve the incoming good mails has to reach us without any issues, and bad mails have tobe blocked here I followed your instructions, now the results from dig is pretty neat. rpm -e djbdns-localcache-1.05-1.0.5 # yum install caching-nameserver bind-chroot and that's it. There should be nothing more to do. (1/5): bind-chroot-9.3.6- 100% |=========================| 44 kB 00:01 (2/5): bind-9.3.6-4.P1.el 100% |=========================| 978 kB 00:07 (3/5): bind-utils-9.3.6-4 100% |=========================| 170 kB 00:02 (4/5): bind-libs-9.3.6-4. 100% |=========================| 857 kB 00:08 (5/5): caching-nameserver 100% |=========================| 60 kB 00:01 Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : bind-libs ######################### [1/7] Installing: bind ######################### [2/7] Installing: caching-nameserver ######################### [3/7] Updating : bind-utils ######################### [4/7] Installing: bind-chroot ######################### [5/7] Cleanup : bind-libs ######################### [6/7] Cleanup : bind-utils ######################### [7/7] Installed: bind-chroot.i386 30:9.3.6-4.P1.el5 caching-nameserver.i386 30:9.3.6-4.P1.el5 Dependency Installed: bind.i386 30:9.3.6-4.P1.el5 Updated: bind-libs.i386 30:9.3.6-4.P1.el5 Dependency Updated: bind-utils.i386 30:9.3.6-4.P1.el5 Complete! /etc/init.d/named restart /etc/init.d/named status number of zones: 6 debug level: 0 xfers running: 0 xfers deferred: 0 soa queries in progress: 0 query logging is OFF recursive clients: 0/1000 tcp clients: 0/100 server is up and running named (pid 382) is running... vow dig @127.0.0.1 google.com ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5 <<>> @127.0.0.1 google.com ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58901 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 0 ;; QUESTION SECTION: ;google.com. IN A ;; ANSWER SECTION: google.com. 300 IN A 74.125.45.100 google.com. 300 IN A 74.125.53.100 google.com. 300 IN A 74.125.67.100 ;; AUTHORITY SECTION: google.com. 172800 IN NS ns2.google.com. google.com. 172800 IN NS ns3.google.com. google.com. 172800 IN NS ns4.google.com. google.com. 172800 IN NS ns1.google.com. ;; Query time: 726 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Dec 3 11:26:58 2009 ;; MSG SIZE rcvd: 148 --Nic > To: [email protected] > From: [email protected] > Date: Wed, 2 Dec 2009 22:33:08 -0700 > Subject: [qmailtoaster] Re: Blocking mail-id's which doesn't exist in > database > > nicole thomson wrote: > > > Eric 'shubes', you are very nice. > > Thanks, Nicole. I try. Sometimes it's easier than others. :) > > > "Which DNS server you use for resolution has nothing to do with rDNS. > > I don't use djbdns (I use caching-nameserver and bind-chroot packages > > instead)" > > > > is there any quick howto caching-nameserver and bind-chroot? > > Simply uninstall your djbdns package (rpm -e <packagename>), then > # yum install caching-nameserver bind-chroot > and that's it. There should be nothing more to do. > > To check to be sure it's running: > # service named status > > To be sure it's being used, 127.0.0.1 should be listed as the first > nameserver in your resolv.conf file, same as djbdns. > > You can test it same as before. Do a 'dig' on some external domain, then > be sure that 127.0.0.1 is listed as the server near the end. > > > so I can't be much help debugging your djbdns setup if it has > > problems. I do know that you can test to see if it's working by doing: > > while your djbdns is running. You should get back: > > > > # dig @127.0.0.1 google.com > > > > > > ; <<>> DiG 9.3.4-P1 <<>> @127.0.0.1 google.com > > ; (1 server found) > > ;; global options: printcmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37789 > > ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > > > > ;; QUESTION SECTION: > > ;google.com. IN A > > > > ;; ANSWER SECTION: > > google.com. 300 IN A 74.125.67.100 > > google.com. 300 IN A 74.125.53.100 > > google.com. 300 IN A 74.125.45.100 > > > > ;; Query time: 2479 msec > > ;; SERVER: 127.0.0.1#53(127.0.0.1) > > ;; WHEN: Thu Dec 3 10:22:24 2009 > > ;; MSG SIZE rcvd: 76 > > > > i didnt get AUTHORITY SECTION: > > I don't know why that would be. Perhaps a difference with djbdns? > > > There should be no functional difference between using djbdns and > > 127.0.0.1 vs your ISP's DNS resolver(s), provided both resolvers are > > working properly. Using djbdns will help your QMT server to run a little > > faster is all. > > > > > > basically here i need to troubleshoot if i use spamdyke, many of my > > users/clients where not able to send mails, > > Were they trying to use your QMT server to send email to an external > domain, or were they trying to send from an external server to your QMT > server? I'm not clear about which you're talking about. > > > sorry to club the other query i made here in list. in smtp/current i > > used to get DENIED_RBLMATCH. > > It's pretty normal to see many of these. It shouldn't be showing up for > IP addresses that aren't listed though. I've never heard of spamdyke > generating this message in error, even if DNS is broken. > > > so i switched (commented) the blacklists > > option. it is pretty difficult to digest that mail server is running > > without spam controller. i was in a impression that since i am not > > running any caching/ server this error would have occured. > > There are a several anti-spam mechanisms in QMT. They'll all work > without a caching nameserver running on QMT, just not quite as quickly. > > > eventhough the ip's where not listed in spamhaus (all three shows OK") > > as follows > > > > IP Address Lookup > > > > 165.21.21.188 is not listed in the SBL > > 165.21.21.188 is not listed in the PBL > > 165.21.21.188 is not listed in the XBL > > I'll believe it when I see it. Will you post a log message showing > DENIED_RBLMATCH with this address? Perhaps that would shed some light on > your trouble. > > # qmlog -lc 165.21.21.188 smtp > should find where this happened in your log. > > If you were using the stock spamdyke settings, it's possible that the > address was listed at bl.spamcop.net at the time. > > I've used zen.spamhaus.org and bl.spamcop.net for quite some time, and > have seen very few false positives. When there is one, it's simple to > whitelist either the domain, rDNS, or IP address. This should only need > to be done while the sending server's admin takes measures to become > delisted. > > > "Please describe any remaining problem you have the best you can, and > > we'll do our best to get you running smoothly." > > > > > > very nice word it is eric, During this thanks giving i would have said > > thanks to you. > > You're quite welcome. I hope you get your trouble resolved with little > more difficulty. > > -- > -Eric 'shubes' > > > --------------------------------------------------------------------------------- > Qmailtoaster is sponsored by Vickers Consulting Group > (www.vickersconsulting.com) > Vickers Consulting Group offers Qmailtoaster support and installations. > If you need professional help with your setup, contact them today! > --------------------------------------------------------------------------------- > Please visit qmailtoaster.com for the latest news, updates, and packages. > > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > _________________________________________________________________ New Windows 7: Find the right PC for you. Learn more. http://windows.microsoft.com/shop
