SMTP and 553 error, rcpthosts

[ContentWriter]

I've read of many people having this problem, and tried the various fixes, but still have the INTERMITTENT problem:

When I try to send mail from various computers in my office, I get:

Error 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)

This is an INTERMITTENT problem. When we send, it will usually fail with this error 2 or 3 times and then it will go thru on the 4th time.

It is very slow every time.

We use the latest Outlook Express as well as Outlook 2003 and various other versions.

However, I have sent test messages from Yahoo accounts, with several email addresses in the cc: list. Strangely, some will get the email fairly quickly, whereas others will not get it for up to about 15 minutes, even though they are all cc: on the exact same email message sent at the exact instant! Just different domains on the same Plesk 8.0 server! Apparently, the Plesk server is also giving problems to the Yahoo mail sender.

Further, some of my emails to/from my other domains on other servers haven't been received. I'm still waiting for emails I sent over an hour ago. Usually, they get thru after just a minute to a few minutes, but sometimes it takes bloody ages. However, these problems do not exist with my non-Plesk servers at the same moment.

It is clear that something needs tweaking on this server. It is also clear from reading others' problems that the QMail on Plesk doesn't work so well as it is configured out of the box, with many people, and there are a lot of opinions it's a QMail issue (right or wrong, i don't know).

This particular server is only about a week old, and I have only a few very low volume domains on it for testing purposes, before I start adding serious business domains to it. My server is not under load.

At first, I couldn't send mail at all, but after researching this problem I followed others' advice on the forums. The server mail settings to 'Relaying ... Authorization is required ... SMTP checked on, POP3 checked on with lock time = 20 minutes.

All clients have "My server requires authentication" checked on, and "Use same settings as my incoming mail server", which is the same as on my other servers.

And it works ... about 25% of the time. The other 75% is frustrating.

I am trying Plesk for the first time. I also use various other control panels and have not experienced this problem with any of them. I can send mail to myself on my other domains on other servers and it gets thru right away. But anytime I send to my Plesk server ... groan ... failures ... delays ...

Everything else on the server runs great, and I like the way the control panel is designed from a usability and organizational viewpoint.

It's only the email that fails. Of course, email is the main purpose / function!

I'm running Plesk 8.0 on Linux Red Hat Fedora Core 4, and I'm running behind a Cisco PIX hardware firewall.

Can anyone here figure out a solution?

 

[prupert]

Are you using the same From address as your login name?

You should enable SMTP authentication within your client. Fill in your username and password manually in stead of "same as incoming mail server".

 

[jamesyeeoc]

And you may or may not have tried adding the -Rt0 option to the smtp_psa file (see other posts), this can cause additional delays for Outlook / OE to connect with the server.

Also, what do you have in the resolv.conf ?

Have you used dnsreport.com to check all hosted domain's DNS being all ok?

 

[ContentWriter]

Yes, I used dnsreport.com and everything looks good.

My original xinetd.d file looked like this, before I added -Rt0 [zero]:

service smtp
{
socket_type = stream
protocol = tcp
wait = no
disable = no
user = root
instances = UNLIMITED
server = /var/qmail/bin/tcp-env
server_args = /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth
/var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
}

I changed it to:

server_args = -Rt0 /var/qmail/bin/relaylock [... etc. ...]

and made sure there were no extra line breaks (using vi)

and restarted all three of DNS, IMAP/POP, and SMTP (QMail).

Still same problem.

There's another user who wrote that adding -Rt0 actually *caused* this problem, i.e., "I have the same problem wih smtp delay and I also fixed this by adding the -Rt0 to the smtp_psa file. But when I did this I could't send mail to other networks, I always got an error: 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)"

Another guy said that adding -Rt0 caused this problem: "But now i realise, mails send out to external domains are not being processed! all stuck in remote queue, but local queue no problem whatsoever... [so i] have removed the -Rt0.."

My resolv.conf file has just one line which is an IP address not associated with my server but associated with my service provider.

I do not have an /etc/inetd.conf file or any inetd.conf file anywhere, but I have an xinetd.conf file so I assume that the server reads this upon bootup and does not need the inetd.conf file. The SWSoft help refers to inetd.conf instead of xinetd.conf

This server is right out of the box, and I haven't deleted anything ...

... well, except one thing. Someone also suggested I delete the PTR record within DNS for my domain, so I did that in only one of my testing domains, and it still has the same problem as my normal domains which have xxx.xxx.xxx.xxx/24

Any more ideas?

Thanks.

 

[ContentWriter]

On the thread below, they are discussing the exact same problem on this thread, same solutions tried, yet no working solutions for them, and they apparently just gave up:

http://forum.swsoft.com/showthread.php?s=&threadid=34263&highlight=Rt0

What is really worrisome is that -- like them -- I have sent many test emails which the Plesk system accepted, but not all of them have been delivered. Likewise, of test emails sent from Yahoo to this Plesk system, for example, of the cc: addresses in the *same* email, some are delivered, some are not, and some are delayed whereby they are received a long time after other messages on the cc: were received.

It appears that it's not just an SMTP problem FROM our domain users, it's also a mail receiving problem from other servers TO our domain users.

More suspicions have arisen when I occasionally receive business emails from people who refer to a previous email which I never received, and also emails asking for a reply when I already replied and the Plesk server had accepted my SMTP session.

Going thru these threads, this appears to be a problem going back thru version 7 of Plesk -- many versions of 7.x and now 8.x

If you didn't receive an email, how would you know you didn't receive it?

 

[jamesyeeoc]

I do recall some of the older threads with same/similar problems. Just some additional questions/things to check/things to try: (You are running a dedicated server, not a VPS?)

1. Disable SELINUX security (I know the problem is intermittent, but why not try?)
2. Disable DrWeb and any other AV scanners
3. Disable Spamassassin
4. Disable any linux firewall

What (if any) other packages have been installed on the server (APF, BFD, anything not pure distro or Plesk supplied at all??) Any other packages you may have upgraded (PHP, MySQL, etc?)

Other comments:
1. Yahoo delays are sometimes on their end (I see this often enough, hotmail is often worse than Yahoo though)
2. Just trying to eliminate additional possibilities with the 3 suggestions above... not permanent solutions... just to narrow the field.
3. Being on the bleeding edge of new releases can and often are troublesome. The last time I tried a '.0' version was Plesk 6.0. With Plesk 7, I waited until 7.5 was released, and I probably will wait for at least 8.2.x...

 

[rviradia]

I am having this same problem on a plesk 8 server (and we host many), I'll keep you posted if I find a fix.

 

[help_me]

migration tool problem

I've had countless problems with plesk and found the documentation and support totally inadequate, really bad move. I found that I had (amongst other) problems with email when I had a domain on both the plesk and it's former server.

Suggest you check that the domain is only in one place.