repeated rejection of lookups of bad name
A few days ago I received a message with a return path of [EMAIL PROTECTED] exim4's data ACL rejected the message. At the same time, my logs show -- Nov 7 22:11:12 corn check[6264]: spamd: got connection over /var/run/spamd/socket Nov 7 22:11:12 corn check[6264]: spamd: checking message 000701c821ce [EMAIL PROTECTED] for mail:8 Nov 7 22:11:17 corn check[6264]: [ 2] [bootup] Logging initiated LogDebugLevel=3 to sys-syslog Nov 7 22:11:18 corn named[3831]: unexpected RCODE (REFUSED) resolving 'palmcoastcondo.com/TXT/IN': ::1#53 Nov 7 22:11:19 corn cyrus/imap[23341]: open: user ross opened INBOX Nov 7 22:11:21 corn check[6264]: [ 3] mail 1 is known spam. - Since then, every hour at 2 minutes after the hour I get the named[]: unexpected RCODE (REFUSED) resolving 'palmcoastcondo.com/TXT/IN': ::1#53 message. Googling indicates this means that a DNS query is going to ::1, which I think is IPv6 for localhost, and the DNS server (which is mine) is rejecting the query. Why is this happening? That is, 1. why is the query being generated every hour? The timing seems to coincide with hourly runs of logcheck. 2. why is it looking for ::1#53 as the DNS server? I have not configured bind9 to accept queries on ::1. So the question isn't why it's being rejected, but why that location is being queried. 3. How can I stop these queries? Also, my logcheck rules aren't filtering th unexpected RCODE messages out. I suspect they should, but the reason will probably be clear by inspecting them. I'm running logcheck, exim4, spamassassin, and cyrus on Debian testing. I had no upgrades/installs immediately preceding the start of this behavior. Thanks. Ross -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repeated rejection of lookups of bad name [DIAGNOSED/SOLVED]
[my original post had an incorrect debian-userS as the list name, which then migrated to the cc of the reply] Forwarded Message From: Ross Boylan [EMAIL PROTECTED] To: Michael Shuler [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: repeated rejection of lookups of bad name Date: Sun, 11 Nov 2007 12:40:13 -0800 On Sun, 2007-11-11 at 13:05 -0600, Michael Shuler wrote: On 11/11/2007 12:47 PM, Ross Boylan wrote: Why is this happening? That is, 1. why is the query being generated every hour? The timing seems to coincide with hourly runs of logcheck. 2. why is it looking for ::1#53 as the DNS server? I have not configured bind9 to accept queries on ::1. So the question isn't why it's being rejected, but why that location is being queried. 3. How can I stop these queries? 1. The mail server queue is likely to be running every hour and just reprocessing. There's nothing in the queue, consistent with the message having been rejected anyway. I ran logcheck from the console and verified that doing so produces the error. I think I know why. The spamassassin report of the mail from logcheck is X-Spam_report: (-1.1 points, 5.0 required) pts rule name description -- -- -0.0 NO_RELAYS Informational: message was not relayed via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.] 2.0 URIBL_BLACKContains an URL listed in the URIBL blacklist [URIs: palmcoastcondo.com] -0.4 AWLAWL: From: address is in the auto white-list So spamassasin is looking in the body of the message and sees the URL. It must then do a lookup of it. This causes an error, which then happens again when logcheck runs again, ad infinitum. 2. Because the palmcoastcondo.com domain owner has borked authoritative servers of ns1./ns2.nameserver.com.. [EMAIL PROTECTED]:~$ host ns1.nameserver.com. ns1.nameserver.com has address 204.77.64.1 ns1.nameserver.com has IPv6 address ::1 [EMAIL PROTECTED]:~$ host ns2.nameserver.com. ns2.nameserver.com has address 127.0.0.1 ns2.nameserver.com has IPv6 address ::1 Ah, so it does a DNS lookup of palmcoastcondo and is told to try ::1, which sends it back to my machine. You can also 'dig any ns1.nameserver.com.' and 'dig any ns2.nameserver.com.' for more detail - records of ::1.. DNS amateurs. And probably UCB, unless you want the condo sales spew.. 3. I would ignore it, and/or remove the messages from the queue, and/or blacklist the domain. I think I'll investigate why logcheck is not filtering out this message, and add something so that it does, at least temporarily. That should put an end to it. [new in this message] The bind patterns for logcheck do not match IPv6 IPs, which looks like an oversight. I'll file a bug. Another approach would be to stop spamassin from checking my internal mails. Thanks for your help. Ross -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: repeated rejection of lookups of bad name
Hi Ross, On Sun, Nov 11, 2007 at 10:47:13AM -0800, Ross Boylan wrote: A few days ago I received a message with a return path of [EMAIL PROTECTED] exim4's data ACL rejected the message. [...] Since then, every hour at 2 minutes after the hour I get the named[]: unexpected RCODE (REFUSED) resolving 'palmcoastcondo.com/TXT/IN': ::1#53 message. Googling indicates this means that a DNS query is going to ::1, which I think is IPv6 for localhost, and the DNS server (which is mine) is rejecting the query. I believe that your DNS server is reporting an error code it is receiving from the auth. servers for palmcoastcondo.com. Why is this happening? That is, 1. why is the query being generated every hour? The timing seems to coincide with hourly runs of logcheck. It is probably being checked by spamassassin's URIBL module as it appears in email going to you. 2. why is it looking for ::1#53 as the DNS server? I have not configured bind9 to accept queries on ::1. So the question isn't why it's being rejected, but why that location is being queried. I imagine that your named is listening on all interfaces. What is in /etc/resolv.conf? 3. How can I stop these queries? There are several ways. For example you could: - stop receiving email with that domain name in it. - Turn off URIBL queries but instead I would recommend ignoring it, and taking steps to make ignoring it easier. Also, my logcheck rules aren't filtering th unexpected RCODE messages out. I suspect they should, but the reason will probably be clear by inspecting them. Usually when I have problems like this with logcheck it is because the message also matches something in the violations files, which are positive matches. I would take a guess at REFUSED being in /etc/logcheck/violations.d/logcheck. Cheers, Andy -- http://bitfolk.com/ -- No-nonsense VPS hosting Encrypted mail welcome - keyid 0x604DE5DB signature.asc Description: Digital signature
