Email not being sent successfully

[RooMeat]

I have problems with emails not being sent to the recipients.. and not sure where to start looking for the problem.
A example... Email sent to a forum member and it is bounced back to me with the following message:
-----------------------------------------------
Hi. This is the qmail-send program at name.server.com.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<[email protected]>:
Sorry, I wasn't able to establish an SMTP connection. (#4.4.1) I'm not going to try again; this message has been in the queue too long.
--------------------------------------------------------------

Yet I can send this exact email to the exact email address from my external email account (email address that does not use my server) and it goes through without a problem.

My server provider tells me there is nothing wrong with the server.. yet emails still have issues.. which tells me there IS a problem somewhere.. just not sure where to start looking.

Server running Cent OS5, PHP5, Plesk 8.6, ASL, 4PSA Spam Guardian and Clean Server.

 

[Ragefast]

First, check the reverse dns for your server's IP is properly configured and responding. Unresponsive dns can cause delay in a lot of anti-spam tools like reverse mx queries, spf, domainkeys, etc, consequently delaying and even timeouting smtp connections.

If all that is fine then try connecting from your server's command line using, for example, 'telnet <dst-mailserver> 25' to see if the server open a smtp session for you. Again, delay before showing you their smtp banner is a good indicative you may have DNS problems.

Also, you may very well be blocked in the other end, so its worth contacting them to check.

 

[RooMeat]

well I ran a test from dnsstuff.com for the reverse dns and got the following:
Preparation:
The reverse DNS entry for an IP is found by reversing the IP, adding it to "in-addr.arpa", and looking up the PTR record.
So, the reverse DNS entry for 208.87.XX.XX is found by looking up the PTR record for
XX.XX.87.208.in-addr.arpa.
All DNS requests start by asking the root servers, and they let us know what to do next.
See How Reverse DNS Lookups Work for more information.

How I am searching:
Asking e.root-servers.net for XX.XX.87.208.in-addr.arpa PTR record:
e.root-servers.net says to go to epazote.arin.net. (zone: 208.in-addr.arpa.)
Asking epazote.arin.net. for XX.XX.87.208.in-addr.arpa PTR record:
epazote.arin.net [192.41.162.32] says to go to NS2.COLOCATEUSA.NET. (zone: XX.87.208.in-addr.arpa.)
Asking NS2.COLOCATEUSA.NET. for XX.XX.87.208.in-addr.arpa PTR record: Reports plesk1.myserver.com. [from 208.75.176.XX]

Answer:
208.87.XX.XX PTR record: plesk1.myserver.com. [TTL 3600s] [A=208.87.XX.XX]


ns2.colocateusa.net [208.75.176.XX] plesk1.myserver.com. 15ms
ns3.colocateusa.net [208.75.183.XX] plesk1.myserver.com. 30ms
ns1.colocateusa.net [208.75.177.XX] plesk1.myserver.com. 15ms

Status: Records all match.

I also tried connecting via telnet and was able to do so without problems or delays.

 

[svaughan]

Like ragefast said, telnet to the mail server hosting the domain on port 25, then attempt to simulate a delivery to that email address. If there are 2 MX's then try both... also check you don't have any entries for this domain in /var/qmail/control/smtproutes

 

[Ragefast]

Note that it is important you do the telnet test from the same box which shows the problem, else it might just work fine.

Just as an example, some time ago I had a problem where my mailserver was having its messages for X mailserver refused because X dns resolver weren't able to resolve my reverse IP, because of misconfiguration from X sysadmin, even tough I my reverse was OK.

Solution was the most painful one, which normally is convince the other sysadmin that he is wrong...