I had a qmail server running (vpopmail, imap) for a few months now... We had trouble to get it working at first but it was eventually resolved.
So I let it run just like that. The guy who installed it, a Linux Redhat techie (which I'm really not :(), got fired a while ago, so I can't count on him, and now we've got a problem... and they're counting on me <ulp>.
Mails aren't getting sent anymore. In the logs I see " CNAME_lookup_failed_temporarily" everywhere. And it seems that it's been doing that for a while, so I'm surprised I there were no complaints earlier!
But anyway... I googled that error message but really couldn't find anything that matched the problem. I mean in my case, it *was* working before! Why would it suddenly stop? O_o Now the queue has tons of messages in it that have never been sent... it's baffling me.
I tried the
echo to: me@wherever | /var/qmail/bin/qmail-inject
from the TEST.deliver, and it didn't work, in the logs I still get the CNAME_lookup error.
What should I do? Keep in mind I'm not utterly clueless when it comes to Linux, but I'm not a pro either. :(
Thanks.
(Edit: they can *receive* mails just fine, and sending to an address on the same domain/server works, ie. myaddy@myserver.com can send to myotheraddy@myserver.com, but not to remoteaddy@remoteserver.com)
From the command line, try:
dig a remoteserver.com
dig mx remoteserver.com
where remoteserver.com is the name of the server you're having trouble sending mail to.
Hmm, it cannot send to -any- mail server except for its own... are you saying I should add every possible domain, ever? :p
are you saying I should add every possible domain, ever?
You can try, if you like. But it's irrelevant for the purposes of this exercise.
Try and run the aforementioned dig commands for a domain that you are having difficulties sending mail to. This should indicate if your server is experiencing general difficulties in resolving names (e.g. failing DNS resolver servers) or if the problem is more specific to qmail (e.g. oversized DNS responses).
Alrighty.
So here's the results (with the domains replaced by a generic name of course)
[root@localhost qmail]# dig a remoteserver.com
; <<>> DiG 9.2.1 <<>> a remoteserver.com
;; global options: printcmd
;; connection timed out; no servers could be reached
[root@localhost qmail]# dig mx remoteserver.com
; <<>> DiG 9.2.1 <<>> mx remoteserver.com
;; global options: printcmd
;; connection timed out; no servers could be reached
Even tried that command with the actual local server, and got the same error:
[root@localhost qmail]# dig mx localserver.com
; <<>> DiG 9.2.1 <<>> mx localserver.com
;; global options: printcmd
;; connection timed out; no servers could be reached
:( I don't know what this stuff means, but perhaps you do? Any idea?
Thanks for your help.
;; connection timed out; no servers could be reached
Your server's ability to resolve names is broken.
What's in your /etc/resolv.conf file?
It says (x'ed last two numbers for privacy):
nameserver 149.99.x.x
And that's it.
What baffles me is that the mail woul work fine just a couple of months ago... Could it be (and I apologize if I'm saying something really stupid or newbie here ;)) something to do with a lack of drive space that f*cked up something? I'm probably wayyy off, but usually (keyword: usually), things don't get broken all of a sudden... hehe.
x'ed last two numbers for privacy
No, don't do that. This afford you no extra privacy at all and makes it impossible for me to help you solve your problem.
Re-post with the complete information that I asked for.
Starting nmap V. 3.00 ( www.insecure.org/nmap/ )
Interesting ports on 149-99-184-138.dsl.mtl1.sprint-canada.net (149.99.184.138):
Port State Service
22/tcp filtered ssh
53/tcp filtered domain
Nmap run completed -- 1 IP address (1 host up) scanned in 40 seconds
[root@vaio root]#
I couldn't resolve any DNS queries using that server, and all the ports appear filtered. I'm assuming (since it's on a DSL range) that 149.99.184.138 is your IP address? If so, is there a DNS resolver (e.g. BIND, dnscache) running on that IP address? If not, then put your ISP's name servers as nameserver entries in /etc/resolv.conf - this will allow your machine to resolve DNS queries again.
Hah! It turns out this IP was totally wrong! It's not even my IP or the server's or anything...
I asked the tech admins (they're finally back, woohoo) about this IP and they seemed confused. I wonder what the hell it was doing in the resolv.conf? :confused:
Well, they gave me the DNS server IP and now it seems to work. I ran the dig command to it too, and got results.
Thanks a million for your help. ^_^ Now... do you have a suggestion as for what I should do with all the email messages in the queue? <blushes> It'll be weird for the recipients to receive old emails, so maybe I should nuke 'em somehow, but then, it might contain important data, so I don't know what to do...
At least it should work fine from now on. Phew.
Now... do you have a suggestion as for what I should do with all the email messages in the queue?
Just wait for a while; qmail will attempt to deliver them according to its own internal schedule.
If you want to force it to attempt delivery for the queue contents now, you can do:
qmailctl doqueue
(assuming you've installed in accordance with the instructions at www.lifewithqmail.org).
Yes, seems like it... I just received a test email I had sent yesterday now.
Oh, well, if anyone ask... it's not me. <looks around suspiciously>
(Actually, it isn't, I never touched that resolv.conf file before and didn't change the DNS, heh).
Thanks again for your help. Now I need to get cranking on enabling pop3 (which is what I was asked to do, but as I went to check it out I noticed the other problem so I resolved to get that fixed first) on the IMAP mail server...