At 4/5/01 08:45 PM +0200, you wrote:
> This may or may not apply to you, but the most frequently seen cause of > this problem is improper reverse DNS resolution. If you do not know what > this is, can't figure it out, or need more help, post again (can't give > more detail 'cause I'm late for a deadline). > > Most common symptom is that mail goes through perfectly but after a long > delay, like 90 seconds. (To most people that feels like a long time.) > Exactly. However symptoms remain even if SMTP server is specified by IP number. Can you in simple words tell what can be wrong with reverse DNS resolution?
(Throughout this discussion, I'm going to assume that reverse DNS is in fact your problem. It may not be, but this is the only way we're going to find out.)
What you're avoiding by inputting the IP address is one name->number conversion done by DNS. However, your problem lies with sendmail, who is trying to protect you from spammers who send to you and spammers who want to use your server to send their shit everywhere, probably crippling your server in the process.
Sendmail can do several checks; like hosts.allow and hosts.deny, some checks are to see if it should specifically allow the mail to be relayed, and some are to see whether it should specifically reject the mail.
So, sendmail gets your IP address from the packet headers (not from anything you tell it), and does a reverse-DNS lookup on it (number->name). Why? It's trying to see whether this IP address belongs to a domain that it *is* allowed to relay for, and this is one of the things it checks (an allow check).
Note that the *absence* of reverse DNS is the problem here. If you had reverse DNS properly set up, and the server was allowed to relay from domain.com, and the reverse DNS converted 111.222.333.444 -> joe.domain.com, then sendmail would allow the relay.
But since you don't have any, sendmail is waiting for the reverse-DNS query to time out, at which point it shrugs and goes on to another check. Since your mail is going through, it means one of those checks is being passed.
Try the following from your Qube, assuming you (the mail client) are joe.domain.com and 111.222.333.444:
[qube]# host joe.domain.com [qube]# host 111.222.333.444The host command will convert name->number or number->name (depending on what you give it) using the Qube's default nameservers. Also read the man pages for nslookup and dig, they're useful tools too.
Both of these queries should give answers quite quickly. In your case, I'm guessing that the second will not return an answer quickly, but rather will time out and say something nasty.
Try this, and let's see what happens. Post the results (but change the domain and IP info to bogus stuff).
-- Rodolfo J. Paiz rpaiz@xxxxxxxxxxxxxx