Email not being delivered

[phantom2]

None of the emails are being delivered on one of my servers.

Here's the errors. I've replaced the real emails with user@email.com

LOG: retry_defer MAIN
== user@email.com R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host

LOG: retry_defer MAIN
== user@email.com R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host


SMTP error from remote mailer after MAIL FROM: SIZE=1488: host mx.east.cox.net [68.1.17.3]: 450 Unable to find one.servername.com


LOG: retry_defer MAIN
== user@email.com routing defer (-51): retry time not reached

Any idea what this could be for? In one of the errors it says it can find the server name "one.servername.com" (which is not the real name. I edited it).

Any ideas on this?

Thanks!

[phantom2]

I actually think i fixed it. I wanted to post the fix because I know how annoyed I get when people post a problem then come back and say "Nevermind, I fixed it" and do not post the solution. CPanel should make it a requirement.

The hostname was not resolving. I deleted the hostname zonefile, clicked on "change hostname". I left the hostname the same but just clicked change. I then added the A entry and it could then resolve.

Now email has started working but there are still some in the mail spool with these errors. I'm thinking that it's just old mail with bad headers.

R=lookuphost T=remote_smtp defer (-53): retry time not reached for any host

routing defer (-51): retry time not reached

What do the errors -51 and -53 refer to?

[ne0shell]

Im seeing this same issue on 2 different servers that were working fine for weeks. I'll try the hostname thing but I'm wondering if an update broke something again.

[ne0shell]

well i found a fix for it, and given I'm seeing this on 2 servers and what the actual problem turned out to be I know more will see it, or might even be suffering it and just assume all those queued messages are bad.....

SSH into your server under root and run this

iptables -L | more

i found this line under chain OUTPUT

target prot opt source destination ACCEPT tcp -- anywhere localhost tcp dpt:smtp REJECT tcp -- anywhere anywhere tcp dpt:smtp reject-

to get rid of it i ran these commands

iptables -D OUTPUT 2
iptables -D OUTPUT 1

emailed flowed correctly after that.


what i found out is the SMTP tweak was enabled and was adding that line on startup.


Thanks to lifeisboost on WHT forums for the answer. Absolutely correct. After this my outbound queue cleared out and email works perfect again.

[SprintSlash]

Originally posted by ne0shell
to get rid of it i ran these commands

iptables -D OUTPUT 2
iptables -D OUTPUT 1

emailed flowed correctly after that.

When you get rid of those lines, doesn't it defeat the purpose of SMTP tweak? i.e. isn't it same as disabling SMTP tweak option?

I've checked the difference between a working and a non-working server, I see this for working server:

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:smtp OWNER GID match mail 
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:smtp OWNER GID match mailman 
ACCEPT     tcp  --  anywhere             anywhere           tcp dpt:smtp OWNER UID match root 
REJECT     tcp  --  anywhere             anywhere           tcp dpt:smtp reject-with icmp-port-unreachable 
acctboth   all  --  anywhere             anywhere

and this for non-working server:

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             localhost          tcp dpt:smtp 
REJECT     tcp  --  anywhere             anywhere           tcp dpt:smtp reject-with icmp-port-unreachable 
acctboth   all  --  anywhere             anywhere

I'm guessing SMTP tweak doesn't work on the non-working server because of those lines. My question is, why aren't those lines added when I enabled SMTP tweak on the non-working server?

[ne0shell]

I'm really not sure to be honest. Enabling SMTP tweak on other systems has never caused a malfunction before. I can only guess maybe the new kernel update combined with a cPanel update broke something. I've run across quite a few people having the exact same issue who've been able to fix it this way which may not be proof of a defect, but its definately a bug worth looking into.