Re: ..::Rbl not working::..
On Aug 22, 2012, at 15:47, /dev/rob0 wrote: Google Public DNS seems to look up records again before the TTL expires in their cache, so you are indeed likely to see a slight improvement in your DNS response time without the doubling of your external queries, when using their service. But is that in any way something you could call net-green? Since they're ignoring the published TTL, I think not. Kinda depends on how they do their pre-fetching, really. Unbound also has an option do this, off by default. But if they were to pre-fetch in the last X minutes before expiry, that shouldn't really be a problem, as long as new data gets picked up on cue? The bigger problem we found with using someone else's recursors in terms of TTL is that quite a few of them seem to override the shorter TTL values. Like, anything less than four hours automatically picks up four hours as a minimum, that sort of thing. Other benefits of running your own nameserver, not to be overlooked: 1. You're shielded from the impact of decisions of greedy business types who don't understand DNS. Every so often one of them gets the idea to replace NXDOMAIN responses with an IP address pointing to their own web server. For a mail server doing DNSBL/DNSWL lookups, the result of that can only be a disaster. And it can happen at any time. Lots of ISPs do this, and they usually won't warn you in advance of such a change. 2. You are in control of your own DNSSEC policy. You can strictly validate all signatures, you can allow expired signatures, or you can choose to ignore DNSSEC altogether. If a zone you know exists suddenly comes up as SERVFAIL, you know what to check. Conversely, if DNS for a signed zone is hijacked while you are checking signatures, you are not going to fall for the bogus data. 3. You control your own cache. If you are aware of cached data being wrong, you can flush that data and move ahead; whereas you cannot flush your forwarder, and you have to wait for the TTL to expire. Propagation is a myth propagated by and for people who don't understand DNS. 4. Relative immunity to DoS attacks, since you can lock down your resolvers to only provide access to your own network, which is usually a whole lot smaller than whatever public or semi-public resolvers you might be using otherwise. 5. The ability to insert your own overrides and redirects. You won't need to override something very often, but it's great to be able to redirect certain queries to rbldnsd running on a different port, for example, if you want to run custom DNS based blacklists. I go for one nameserver per site, or at a bigger site, maybe two. For those running just one or two servers, this can even be as simple as running a recursor on your localhost interface, making sure it starts before everything else does. Cya, Jona
Re: ..::Rbl not working::..
On Tue, Aug 21, 2012 at 7:52 PM, /dev/rob0 r...@gmx.co.uk wrote: On Tue, Aug 21, 2012 at 09:03:47AM -0500, Alfonso Alejandro Reyes Jiménez wrote: I've postfix working great but I cant make the rbl works, I have the configuration but when I test the configuration it seems not to be working. I'm testing with http://www.crynwr.com/spam/ Spamhaus has that ip address listed but I'm still getting those emails. Here's the postconf -n result: [root@mail ~]# postconf -n Irrelevant parts removed, possibly relevant lines here: mynetworks = 127.0.0.0/8, 10.1.8.27/32, 10.1.8.23/32, 172.16.18.101/32, 10.1.215.26/32 smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_rbl_client zen.spamhaus.org,reject_rhsbl_sender dsn.rfc-ignorant.org,reject_unauth_destination any ideas? thanks in advance for your help. You neglected to show the logs of the acceptance of the crynwr.com test mail. Nevertheless, I do have a WAG for you. Test your server's ability to resolve records in zen.spamhaus.org. [alfonso@mail ~]$ dig 2.0.0.127.zen.spamhaus.org. any You should see among the output: ;; ANSWER SECTION: 2.0.0.127.zen.spamhaus.org. 300 IN TXT http://www.spamhaus.org/query/bl?ip=127.0.0.2; 2.0.0.127.zen.spamhaus.org. 300 IN TXT http://www.spamhaus.org/sbl/query/SBL233; 2.0.0.127.zen.spamhaus.org. 300 IN A 127.0.0.4 2.0.0.127.zen.spamhaus.org. 300 IN A 127.0.0.10 2.0.0.127.zen.spamhaus.org. 300 IN A 127.0.0.2 If you're using a nameserver external to you, such as Google Public DNS or any ISP's resolver, there is a very good chance that Spamhaus is blocking your queries. If my guess is right, you can possibly fix it by installing and using your own local caching resolver, i.e., BIND named(8) or other implementation of DNS recursion. Offer void where taxed or restricted, or if your number of queries puts you in excess of Spamhaus maximum allowed. (In that case, see about their paid service; well worth the small expense per mailbox.) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: I never realized that I had this issue too. But, after running the tests, I found out that my queries were indeed blocked by spamhaus. So, I changed the servers as pointed out and bingo, spam was successfully being blocked. Thanks /dev/rob0
Re: ..::Rbl not working::..
On Wed, Aug 22, 2012 at 01:23:12PM +0530, DN Singh wrote: I never realized that I had this issue too. But, after running the tests, I found out that my queries were indeed blocked by spamhaus. So, I changed the servers as pointed out and bingo, spam was successfully being blocked. Thanks /dev/rob0 Hehe, glad to hear it! And best of all, from someone with the initials, DNS! ;) Many people think that using forwarders rather than recursion is somehow more effective or net-green (conserving of the network resources provided by others.) It's really not, and it carries an added risk of external cache poisoning. If you query a record from a forwarder, and the forwarder has it cached, yes, you get a quick response from said forwarder. But you get a cached record, which means the TTL is ticking away. You get, on average, half the published TTL, which means you'll do, on average, twice the number of queries. If you query a record from a forwarder, and the forwarder does NOT have it cached, you have introduced extra latency in getting your reply whilst the forwarder recurses. (But you end up with the full TTL minus the latency.) Google Public DNS seems to look up records again before the TTL expires in their cache, so you are indeed likely to see a slight improvement in your DNS response time without the doubling of your external queries, when using their service. But is that in any way something you could call net-green? Since they're ignoring the published TTL, I think not. Other benefits of running your own nameserver, not to be overlooked: 1. You're shielded from the impact of decisions of greedy business types who don't understand DNS. Every so often one of them gets the idea to replace NXDOMAIN responses with an IP address pointing to their own web server. For a mail server doing DNSBL/DNSWL lookups, the result of that can only be a disaster. And it can happen at any time. Lots of ISPs do this, and they usually won't warn you in advance of such a change. 2. You are in control of your own DNSSEC policy. You can strictly validate all signatures, you can allow expired signatures, or you can choose to ignore DNSSEC altogether. If a zone you know exists suddenly comes up as SERVFAIL, you know what to check. Conversely, if DNS for a signed zone is hijacked while you are checking signatures, you are not going to fall for the bogus data. 3. You control your own cache. If you are aware of cached data being wrong, you can flush that data and move ahead; whereas you cannot flush your forwarder, and you have to wait for the TTL to expire. Propagation is a myth propagated by and for people who don't understand DNS. I go for one nameserver per site, or at a bigger site, maybe two. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: ..::Rbl not working::..
/dev/rob0: Google Public DNS seems to look up records again before the TTL expires in their cache, so you are indeed likely to see a slight There is an article that shows that different resolvers report TTL values in different ways. Begin quote: For a record initially served with a TTL equal to N by authoritative servers: * Google DNS serves it with a TTL in the interval [0, N-1] * dnscache is serving it with a TTL in the interval [0, N] * Unbound serves it with a TTL in the interval [0, N] * Bind serves it with a TTL in the interval [1, N] * PowerDNS Recursor always serves it with a TTL of N End quote. http://00f.net/2011/11/17/how-long-does-a-dns-ttl-last/ Wietse
Re: ..::Rbl not working::..
[ /dev/rob0 wrote on Wed 22.Aug'12 at 8:47:06 -0500 ] On Wed, Aug 22, 2012 at 01:23:12PM +0530, DN Singh wrote: I never realized that I had this issue too. But, after running the tests, I found out that my queries were indeed blocked by spamhaus. So, I changed the servers as pointed out and bingo, spam was successfully being blocked. Thanks /dev/rob0 Hehe, glad to hear it! And best of all, from someone with the initials, DNS! ;) Many people think that using forwarders rather than recursion is somehow more effective or net-green (conserving of the network resources provided by others.) It's really not, and it carries an added risk of external cache poisoning. If you query a record from a forwarder, and the forwarder has it cached, yes, you get a quick response from said forwarder. But you get a cached record, which means the TTL is ticking away. You get, on average, half the published TTL, which means you'll do, on average, twice the number of queries. If you query a record from a forwarder, and the forwarder does NOT have it cached, you have introduced extra latency in getting your reply whilst the forwarder recurses. (But you end up with the full TTL minus the latency.) Google Public DNS seems to look up records again before the TTL expires in their cache, so you are indeed likely to see a slight improvement in your DNS response time without the doubling of your external queries, when using their service. But is that in any way something you could call net-green? Since they're ignoring the published TTL, I think not. Other benefits of running your own nameserver, not to be overlooked: 1. You're shielded from the impact of decisions of greedy business types who don't understand DNS. Every so often one of them gets the idea to replace NXDOMAIN responses with an IP address pointing to their own web server. For a mail server doing DNSBL/DNSWL lookups, the result of that can only be a disaster. And it can happen at any time. Lots of ISPs do this, and they usually won't warn you in advance of such a change. 2. You are in control of your own DNSSEC policy. You can strictly validate all signatures, you can allow expired signatures, or you can choose to ignore DNSSEC altogether. If a zone you know exists suddenly comes up as SERVFAIL, you know what to check. Conversely, if DNS for a signed zone is hijacked while you are checking signatures, you are not going to fall for the bogus data. 3. You control your own cache. If you are aware of cached data being wrong, you can flush that data and move ahead; whereas you cannot flush your forwarder, and you have to wait for the TTL to expire. Propagation is a myth propagated by and for people who don't understand DNS. I experienced this issue earlier this week when I was setting up my DNS server on my FreeBSD machine. Their Handbook article[1] kind-of implied (at least to me) that using a forwarder was a good idea; however, it was immediately clear after setting it up that it wasn't doing me any favours. The article itself is good and would be worthwhile reading if you're setting your own DNS server up for the first time but everything /dev/rob0 has advised rings true for me. My local network works much more smoothly now since setting up BIND/named on my FreeBSD server. 1 - http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-dns.html
Re: ..::Rbl not working::..
* Alfonso Alejandro Reyes Jiménez are...@ibossmonitor.com: Hi everyone. I've postfix working great but I cant make the rbl works, I have the configuration but when I test the configuration it seems not to be working. Logs? I'm testing with http://www.crynwr.com/spam/ Spamhaus has that ip address listed but I'm still getting those emails. Which IP? Logs? smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_rbl_client zen.spamhaus.org,reject_rhsbl_sender dsn.rfc-ignorant.org,reject_unauth_destination That looks ok -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: ..::Rbl not working::..
On Tue, Aug 21, 2012 at 09:03:47AM -0500, Alfonso Alejandro Reyes Jiménez wrote: I've postfix working great but I cant make the rbl works, I have the configuration but when I test the configuration it seems not to be working. I'm testing with http://www.crynwr.com/spam/ Spamhaus has that ip address listed but I'm still getting those emails. Here's the postconf -n result: [root@mail ~]# postconf -n Irrelevant parts removed, possibly relevant lines here: mynetworks = 127.0.0.0/8, 10.1.8.27/32, 10.1.8.23/32, 172.16.18.101/32, 10.1.215.26/32 smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_rbl_client zen.spamhaus.org,reject_rhsbl_sender dsn.rfc-ignorant.org,reject_unauth_destination any ideas? thanks in advance for your help. You neglected to show the logs of the acceptance of the crynwr.com test mail. Nevertheless, I do have a WAG for you. Test your server's ability to resolve records in zen.spamhaus.org. [alfonso@mail ~]$ dig 2.0.0.127.zen.spamhaus.org. any You should see among the output: ;; ANSWER SECTION: 2.0.0.127.zen.spamhaus.org. 300 IN TXT http://www.spamhaus.org/query/bl?ip=127.0.0.2; 2.0.0.127.zen.spamhaus.org. 300 IN TXT http://www.spamhaus.org/sbl/query/SBL233; 2.0.0.127.zen.spamhaus.org. 300 IN A 127.0.0.4 2.0.0.127.zen.spamhaus.org. 300 IN A 127.0.0.10 2.0.0.127.zen.spamhaus.org. 300 IN A 127.0.0.2 If you're using a nameserver external to you, such as Google Public DNS or any ISP's resolver, there is a very good chance that Spamhaus is blocking your queries. If my guess is right, you can possibly fix it by installing and using your own local caching resolver, i.e., BIND named(8) or other implementation of DNS recursion. Offer void where taxed or restricted, or if your number of queries puts you in excess of Spamhaus maximum allowed. (In that case, see about their paid service; well worth the small expense per mailbox.) -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: ..::Rbl not working::..
On 8/21/2012 10:03 AM, Alfonso Alejandro Reyes Jiménez wrote: Hi everyone. I've postfix working great but I cant make the rbl works, I have the configuration but when I test the configuration it seems not to be working. I'm testing with http://www.crynwr.com/spam/ Spamhaus has that ip address listed but I'm still getting those emails. As others have noted, you need a caching DNS resolver (named, unbound, etc) and you should use dig or host to test. smtpd_banner = $myhostname Microsoft ESMTP MAIL Service ready No benefit to change this. Lying to computers does nothing. smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_rbl_client zen.spamhaus.org,reject_rhsbl_sender dsn.rfc-ignorant.org,reject_unauth_destination I would recommend putting reject_unauth_destination before RBL checks. This will cut down the number of DNS queries which are limited amounts for the free access. Brian
Re: ..::Rbl not working::..
On 8/21/12 9:20 AM, Ralf Hildebrandt wrote: * Alfonso Alejandro Reyes Jiménezare...@ibossmonitor.com: Hi everyone. I've postfix working great but I cant make the rbl works, I have the configuration but when I test the configuration it seems not to be working. Logs? I'm testing with http://www.crynwr.com/spam/ Spamhaus has that ip address listed but I'm still getting those emails. Which IP? Logs? smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_rbl_client zen.spamhaus.org,reject_rhsbl_sender dsn.rfc-ignorant.org,reject_unauth_destination That looks ok I'm sorry I forgot that information. Logs: Aug 21 08:01:48 mail postfix/smtpd[23635]: warning: 200.77.229.165: address not listed for hostname correo2.test.com.mx Aug 21 08:03:32 mail postfix/smtpd[23635]: warning: 200.77.229.166: address not listed for hostname correo3.test.com.mx Aug 21 08:52:11 mail postfix/smtpd[23847]: warning: 200.13.34.22: address not listed for hostname correo4.test.com.mx I couldn't find more logs about. The IP that's testing my mail server is 192.203.178.107, I used the spamhaus lookup tool to confirm that the IP was listed. Aug 21 09:33:58 mail postfix/smtpd[24060]: connect from sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/smtpd[24060]: AB5455D5: client=sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/cleanup[24065]: AB5455D5: message-id=1345559...@sbl.crynwr.com Aug 21 09:33:59 mail postfix/smtpd[24060]: disconnect from sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/smtpd[24060]: AB5455D5: client=sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/cleanup[24065]: AB5455D5: message-id=1345559...@sbl.crynwr.com Aug 21 09:33:59 mail postfix/qmgr[20868]: AB5455D5: from=, size=393, nrcpt=1 (queue active) Aug 21 09:33:59 mail postfix/local[24067]: AB5455D5: to=are...@domain123.com, relay=local, delay=0.87, delays=0.48/0.01/0/0.38, dsn=2.0.0, status=sent (delivered to maildir) Aug 21 09:33:59 mail postfix/qmgr[20868]: AB5455D5: removed That email was delivered. Regards.
Re: ..::Rbl not working::..
On Tue, Aug 21, 2012 at 09:03:47AM -0500, Alfonso Alejandro Reyes Jiménez wrote: I've postfix working great but I cant make the rbl works, I have the configuration but when I test the configuration it seems not to be working. I'm testing with http://www.crynwr.com/spam/ Spamhaus has that ip address listed but I'm still getting those emails. Here's the postconf -n result: [root@mail ~]# postconf -n Irrelevant parts removed, possibly relevant lines here: mynetworks = 127.0.0.0/8, 10.1.8.27/32, 10.1.8.23/32, 172.16.18.101/32, 10.1.215.26/32 smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_rbl_client zen.spamhaus.org,reject_rhsbl_sender dsn.rfc-ignorant.org,reject_unauth_destination any ideas? thanks in advance for your help. You neglected to show the logs of the acceptance of the crynwr.com test mail. Nevertheless, I do have a WAG for you. Test your server's ability to resolve records in zen.spamhaus.org. [alfonso@mail ~]$ dig 2.0.0.127.zen.spamhaus.org. any You should see among the output: ;; ANSWER SECTION: 2.0.0.127.zen.spamhaus.org. 300 IN TXT http://www.spamhaus.org/query/bl?ip=127.0.0.2; 2.0.0.127.zen.spamhaus.org. 300 IN TXT http://www.spamhaus.org/sbl/query/SBL233; 2.0.0.127.zen.spamhaus.org. 300 IN A 127.0.0.4 2.0.0.127.zen.spamhaus.org. 300 IN A 127.0.0.10 2.0.0.127.zen.spamhaus.org. 300 IN A 127.0.0.2 If you're using a nameserver external to you, such as Google Public DNS or any ISP's resolver, there is a very good chance that Spamhaus is blocking your queries. If my guess is right, you can possibly fix it by installing and using your own local caching resolver, i.e., BIND named(8) or other implementation of DNS recursion. Offer void where taxed or restricted, or if your number of queries puts you in excess of Spamhaus maximum allowed. (In that case, see about their paid service; well worth the small expense per mailbox.) I'm sorry I forgot that information. Logs: Aug 21 08:01:48 mail postfix/smtpd[23635]: warning: 200.77.229.165: address not listed for hostname correo2.test.com.mx Aug 21 08:03:32 mail postfix/smtpd[23635]: warning: 200.77.229.166: address not listed for hostname correo3.test.com.mx Aug 21 08:52:11 mail postfix/smtpd[23847]: warning: 200.13.34.22: address not listed for hostname correo4.test.com.mx I couldn't find more logs about. The IP that's testing my mail server is 192.203.178.107, I used the spamhaus lookup tool to confirm that the IP was listed. Aug 21 09:33:58 mail postfix/smtpd[24060]: connect from sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/smtpd[24060]: AB5455D5: client=sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/cleanup[24065]: AB5455D5: message-id=1345559...@sbl.crynwr.com Aug 21 09:33:59 mail postfix/smtpd[24060]: disconnect from sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/smtpd[24060]: AB5455D5: client=sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/cleanup[24065]: AB5455D5: message-id=1345559...@sbl.crynwr.com Aug 21 09:33:59 mail postfix/qmgr[20868]: AB5455D5: from=, size=393, nrcpt=1 (queue active) Aug 21 09:33:59 mail postfix/local[24067]: AB5455D5: to=are...@domain123.com, relay=local, delay=0.87, delays=0.48/0.01/0/0.38, dsn=2.0.0, status=sent (delivered to maildir) Aug 21 09:33:59 mail postfix/qmgr[20868]: AB5455D5: removed That email was delivered. Thanks for the tip but I have bind running and it seems not to be allowed to make queries to spamhaus: [root@mail ~]# dig 2.0.0.127.zen.spamhaus.org any ; DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.2 2.0.0.127.zen.spamhaus.org any ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 35309 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;2.0.0.127.zen.spamhaus.org.INANY ;; AUTHORITY SECTION: zen.spamhaus.org.6INSOAneed.to.know.only. hostmaster.spamhaus.org. 1208211440 3600 600 432000 150 ;; Query time: 71 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Aug 21 09:44:12 2012 ;; MSG SIZE rcvd: 108 [root@mail ~]# Here's the DNS config part: [root@mail ~]# vi /etc/resolv.conf # Generated by NetworkManager nameserver 127.0.0.1 The BIND forwarding is made to a public dns do you think that could be the problem? Regards.
Re: ..::Rbl not working::..
* Alfonso Alejandro Reyes Jiménez are...@ibossmonitor.com: The IP that's testing my mail server is 192.203.178.107, I used the spamhaus lookup tool to confirm that the IP was listed. 192.203.178.107 is indeed listed. $ host 107.178.203.192.zen.spamhaus.org 107.178.203.192.zen.spamhaus.org has address 127.0.0.2 try host 107.178.203.192.zen.spamhaus.org on your box. Aug 21 09:33:58 mail postfix/smtpd[24060]: connect from sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/smtpd[24060]: AB5455D5: client=sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/cleanup[24065]: AB5455D5: message-id=1345559...@sbl.crynwr.com Aug 21 09:33:59 mail postfix/smtpd[24060]: disconnect from sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/smtpd[24060]: AB5455D5: client=sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/cleanup[24065]: AB5455D5: message-id=1345559...@sbl.crynwr.com Aug 21 09:33:59 mail postfix/qmgr[20868]: AB5455D5: from=, size=393, nrcpt=1 (queue active) Aug 21 09:33:59 mail postfix/local[24067]: AB5455D5: to=are...@domain123.com, relay=local, delay=0.87, delays=0.48/0.01/0/0.38, dsn=2.0.0, status=sent (delivered to maildir) Aug 21 09:33:59 mail postfix/qmgr[20868]: AB5455D5: removed That email was delivered. Regards. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: ..::Rbl not working::..
On 8/21/12 9:25 AM, Brian Evans - Postfix List wrote: On 8/21/2012 10:03 AM, Alfonso Alejandro Reyes Jiménez wrote: Hi everyone. I've postfix working great but I cant make the rbl works, I have the configuration but when I test the configuration it seems not to be working. I'm testing with http://www.crynwr.com/spam/ Spamhaus has that ip address listed but I'm still getting those emails. As others have noted, you need a caching DNS resolver (named, unbound, etc) and you should use dig or host to test. smtpd_banner = $myhostname Microsoft ESMTP MAIL Service ready No benefit to change this. Lying to computers does nothing. smtpd_recipient_restrictions = permit_mynetworks,permit_sasl_authenticated,reject_rbl_client zen.spamhaus.org,reject_rhsbl_sender dsn.rfc-ignorant.org,reject_unauth_destination I would recommend putting reject_unauth_destination before RBL checks. This will cut down the number of DNS queries which are limited amounts for the free access. Brian Thanks for the tips, we have bind running on the server forwarded to a public DNS server. We are not lying to computers we are lying to nessus and that kind of software, is part of the systems hardening but thanks for the tip. I will follow your recomendation about the reject_unauth_destination. Any other tip? Regards.
Re: ..::Rbl not working::..
On 8/21/12 9:46 AM, Ralf Hildebrandt wrote: * Alfonso Alejandro Reyes Jiménezare...@ibossmonitor.com: The IP that's testing my mail server is 192.203.178.107, I used the spamhaus lookup tool to confirm that the IP was listed. 192.203.178.107 is indeed listed. $ host 107.178.203.192.zen.spamhaus.org 107.178.203.192.zen.spamhaus.org has address 127.0.0.2 try host 107.178.203.192.zen.spamhaus.org on your box. Aug 21 09:33:58 mail postfix/smtpd[24060]: connect from sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/smtpd[24060]: AB5455D5: client=sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/cleanup[24065]: AB5455D5: message-id=1345559...@sbl.crynwr.com Aug 21 09:33:59 mail postfix/smtpd[24060]: disconnect from sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/smtpd[24060]: AB5455D5: client=sbl.crynwr.com[192.203.178.107] Aug 21 09:33:58 mail postfix/cleanup[24065]: AB5455D5: message-id=1345559...@sbl.crynwr.com Aug 21 09:33:59 mail postfix/qmgr[20868]: AB5455D5: from=, size=393, nrcpt=1 (queue active) Aug 21 09:33:59 mail postfix/local[24067]: AB5455D5: to=are...@domain123.com, relay=local, delay=0.87, delays=0.48/0.01/0/0.38, dsn=2.0.0, status=sent (delivered to maildir) Aug 21 09:33:59 mail postfix/qmgr[20868]: AB5455D5: removed That email was delivered. Regards. Thanks it seems to be an issue with spamhaus, here's the result: [root@mail ~]# host 107.178.203.192.zen.spamhaus.org Host 107.178.203.192.zen.spamhaus.org not found: 3(NXDOMAIN) [root@mail ~]# Any tips that can solve this issue? (I know this is not a bind list, but anyone may had the same issue) Thanks for your help. Regards.
Re: ..::Rbl not working::..
* Alfonso Alejandro Reyes Jiménez are...@ibossmonitor.com: Thanks it seems to be an issue with spamhaus, here's the result: [root@mail ~]# host 107.178.203.192.zen.spamhaus.org Host 107.178.203.192.zen.spamhaus.org not found: 3(NXDOMAIN) [root@mail ~]# Use a proper DNS server (like somebody on this thread already suggested) -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: ..::Rbl not working::..
On 8/21/12 9:57 AM, Ralf Hildebrandt wrote: * Alfonso Alejandro Reyes Jiménezare...@ibossmonitor.com: Thanks it seems to be an issue with spamhaus, here's the result: [root@mail ~]# host 107.178.203.192.zen.spamhaus.org Host 107.178.203.192.zen.spamhaus.org not found: 3(NXDOMAIN) [root@mail ~]# Use a proper DNS server (like somebody on this thread already suggested) Thanks as I was telling I have one, but I think the issue is with the forwarding it's been made to a public dns server. Should I change it to a particular one? (ex spamhaus) Regards.
Re: ..::Rbl not working::..
* Alfonso Alejandro Reyes Jiménez are...@ibossmonitor.com: Thanks as I was telling I have one, but I think the issue is with the forwarding Yes. Why are you forwarding at all? Simply let you DNS recurse cache. -- Ralf Hildebrandt Geschäftsbereich IT | Abteilung Netzwerk Charité - Universitätsmedizin Berlin Campus Benjamin Franklin Hindenburgdamm 30 | D-12203 Berlin Tel. +49 30 450 570 155 | Fax: +49 30 450 570 962 ralf.hildebra...@charite.de | http://www.charite.de
Re: ..::Rbl not working::..
On 8/21/2012 11:02 AM, Alfonso Alejandro Reyes Jiménez wrote: On 8/21/12 9:57 AM, Ralf Hildebrandt wrote: * Alfonso Alejandro Reyes Jiménezare...@ibossmonitor.com: Thanks it seems to be an issue with spamhaus, here's the result: [root@mail ~]# host 107.178.203.192.zen.spamhaus.org Host 107.178.203.192.zen.spamhaus.org not found: 3(NXDOMAIN) [root@mail ~]# Use a proper DNS server (like somebody on this thread already suggested) Thanks as I was telling I have one, but I think the issue is with the forwarding it's been made to a public dns server. Should I change it to a particular one? (ex spamhaus) Regards. If you are running BIND named, you shouldn't need to forward. It knows how to query directly. If your provider blocks DNS requests, then you need to take it up with them. Brian
Re: ..::Rbl not working::..
On Tue, Aug 21, 2012 at 09:45:50AM -0500, Alfonso Alejandro Reyes Jiménez wrote: Thanks for the tip but I have bind running and it seems not to be allowed to make queries to spamhaus: [root@mail ~]# dig 2.0.0.127.zen.spamhaus.org any ; DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.2 2.0.0.127.zen.spamhaus.org any ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 35309 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;2.0.0.127.zen.spamhaus.org.INANY ;; AUTHORITY SECTION: zen.spamhaus.org.6INSOAneed.to.know.only. hostmaster.spamhaus.org. 1208211440 3600 600 432000 150 ;; Query time: 71 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Aug 21 09:44:12 2012 ;; MSG SIZE rcvd: 108 [root@mail ~]# Here's the DNS config part: [root@mail ~]# vi /etc/resolv.conf # Generated by NetworkManager nameserver 127.0.0.1 The BIND forwarding is made to a public dns do you think that could be the problem? rob0 quoted from upthread: If you're using a nameserver external to you, such as Google Public DNS or any ISP's resolver, there is a very good chance that Spamhaus is blocking your queries. If my guess is right, you can possibly fix it by installing and using your own local caching resolver, i.e., BIND named(8) or other implementation of DNS recursion. Offer void where taxed or That was my guess. Now it seems to be confirmed. Remove the forwarders from named.conf(5), ensure that recursion is allowed at least for localhost[1], rndc reload, test again. If the test fails again, you might have to flush the cache. Another rndc(8) subcommand can do that also. We're off topic here. If you need further help with BIND, follow up on the bind-users mailing list at ISC.org. Or, see my URL below; I can fix this for a minimal fee. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: ..::Rbl not working::..
Zitat von Alfonso Alejandro Reyes Jiménez are...@ibossmonitor.com: On 8/21/12 9:57 AM, Ralf Hildebrandt wrote: * Alfonso Alejandro Reyes Jiménezare...@ibossmonitor.com: Thanks it seems to be an issue with spamhaus, here's the result: [root@mail ~]# host 107.178.203.192.zen.spamhaus.org Host 107.178.203.192.zen.spamhaus.org not found: 3(NXDOMAIN) [root@mail ~]# Use a proper DNS server (like somebody on this thread already suggested) Thanks as I was telling I have one, but I think the issue is with the forwarding it's been made to a public dns server. Should I change it to a particular one? (ex spamhaus) Note that public recursor like for example 8.8.8.8 typically exceed the limit of queries spamhaus is willing to accept per source and are therefore blocked. For RBL queries you really should not use a public forwarder. Regards Andreas smime.p7s Description: S/MIME Cryptographic Signature
Re: ..::Rbl not working::..
On 8/21/12 10:06 AM, /dev/rob0 wrote: On Tue, Aug 21, 2012 at 09:45:50AM -0500, Alfonso Alejandro Reyes Jiménez wrote: Thanks for the tip but I have bind running and it seems not to be allowed to make queries to spamhaus: [root@mail ~]# dig 2.0.0.127.zen.spamhaus.org any ; DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.2 2.0.0.127.zen.spamhaus.org any ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 35309 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;2.0.0.127.zen.spamhaus.org.INANY ;; AUTHORITY SECTION: zen.spamhaus.org.6INSOAneed.to.know.only. hostmaster.spamhaus.org. 1208211440 3600 600 432000 150 ;; Query time: 71 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue Aug 21 09:44:12 2012 ;; MSG SIZE rcvd: 108 [root@mail ~]# Here's the DNS config part: [root@mail ~]# vi /etc/resolv.conf # Generated by NetworkManager nameserver 127.0.0.1 The BIND forwarding is made to a public dns do you think that could be the problem? rob0 quoted from upthread: If you're using a nameserver external to you, such as Google Public DNS or any ISP's resolver, there is a very good chance that Spamhaus is blocking your queries. If my guess is right, you can possibly fix it by installing and using your own local caching resolver, i.e., BIND named(8) or other implementation of DNS recursion. Offer void where taxed or That was my guess. Now it seems to be confirmed. Remove the forwarders from named.conf(5), ensure that recursion is allowed at least for localhost[1], rndc reload, test again. If the test fails again, you might have to flush the cache. Another rndc(8) subcommand can do that also. We're off topic here. If you need further help with BIND, follow up on the bind-users mailing list at ISC.org. Or, see my URL below; I can fix this for a minimal fee. That did the trick thanks to everyone that tried to help me with my issue. Regards. Alfonso.
Re: ..::Rbl not working::..
On Tue, Aug 21, 2012 at 10:06:34AM -0500, I wrote: That was my guess. Now it seems to be confirmed. Remove the forwarders from named.conf(5), ensure that recursion is allowed at least for localhost[1], rndc reload, test again. If the test fails again, you might have to flush the cache. Another rndc(8) subcommand can do that also. Ooops, I meant to put a footnote there: [1] localhost in named.conf terms is a built-in ACL which includes any IP address bound on the server itself. See the BIND 9 ARM, Chapter 6, acl Statement Definition and Usage. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
Re: ..::Rbl not working::..
Den 2012-08-21 16:53, Alfonso Alejandro Reyes Jiménez skrev: [root@mail ~]# host 107.178.203.192.zen.spamhaus.org Host 107.178.203.192.zen.spamhaus.org not found: 3(NXDOMAIN) [root@mail ~]# dig +trace 107.178.203.192.zen.spamhaus.org where does it fail ? then contact the nameservers that reject you queries
Re: ..::Rbl not working::..
Den 2012-08-21 17:02, Alfonso Alejandro Reyes Jiménez skrev: Thanks as I was telling I have one, but I think the issue is with the forwarding it's been made to a public dns server. Should I change it to a particular one? (ex spamhaus) no just remove ALL forwarding !
Re: ..::Rbl not working::..
On 8/21/12 11:23 AM, Benny Pedersen wrote: Den 2012-08-21 17:02, Alfonso Alejandro Reyes Jiménez skrev: Thanks as I was telling I have one, but I think the issue is with the forwarding it's been made to a public dns server. Should I change it to a particular one? (ex spamhaus) no just remove ALL forwarding ! Thanks now it's working. Regards,
