• If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion

Email redirects all bounce

J

joeybutterface

Guest
I've run into a strange problem.

Any email redirects setup for an externally hosted email address bounce. I've tested this on Yahoo, Hotmail, Gmail, and my ISP email servers. When I send an email to addresses such as the following:

[email protected]

That should redirect to
[email protected]

The maillog reports this error message:
May 8 03:45:51 server qmail: 1210232751.151469 delivery 4556: failure: Connected_to_xx.xx.x.x_but_sender_was_rejected./Remote_host_said:_501_<#@[]>:
_domain_literals_not_allowed/

And the message bounces back to me with:
<[email protected]>:
handlers permanentfail

I've tried this for a variety of local hosted domains on the Plesk server and they all bounce. Local redirects work fine to addresses hosted on the same machine.

Any ideas?
 
Anyone have any ideas on solving this? The problem also occurs in our Plesk 8.3 server. So it's not related to the upgrade.
 
I got the same Problem with Red Hat 5. Please some know the answer!?!?
 
I've tried it on Plesk 8.3 and 8.4 on different Linux platforms and all of them have the same problem with redirects. There is some older comments about this but apparently nobody cares enough about the problem. The Qmail configuration basically sends malformed redirects to external servers and many of them will reject it with the error I posted above.

So far I've found:
Two of my ISPs mailservers reject all Plesk redirects
Yahoo rejects Plesk redirects
Gmail rejects Plesk redirects

So basically email forwarding is broken if you want to forward messages off site.
 
I've tried it on Plesk 8.3 and 8.4 on different Linux platforms and all of them have the same problem with redirects. There is some older comments about this but apparently nobody cares enough about the problem. The Qmail configuration basically sends malformed redirects to external servers and many of them will reject it with the error I posted above.

So far I've found:
Two of my ISPs mailservers reject all Plesk redirects
Yahoo rejects Plesk redirects
Gmail rejects Plesk redirects

So basically email forwarding is broken if you want to forward messages off site.

Hello joeybutterface,

We cannot reproduce the issue in our lab.
Could you send me PM w/ detailed scenario how to reproduce and credentials to your problem server?
 
Redirect errors to Google

We are having the same issue with redirects. Started with the upgrade to 8.4.
Here's how I see the error.

If an email account has either a redirect or mail group and I send an email TO this local email address from a GMAIL or YAHOO email account, the redirect to GMAIL and YAHOO is bounced back. Also the email sent from Gmail receives a message that the message was not sent and bounced back, but in fact the message does go through to the local email account and is received by the mail account without an error message.

If I send a message from a non-Gmail account (such as Verizon email) the email goes to my host email account and is redirected to the GMAIL account without error or bounce messages, but not to the YAHOO account which is also on the redirect.

Totally confused.
Settings are: SpamAssassin ON, DomainKeys ON (outgoing) OFF (incoming), Dr.WEb (OFF as this was generating over 6000 error messages in one hour), COS4.2 Plesk 8.4, use long names for accounts.

I've attached two files:
1) gmail-bounce.txt - the email from the Gmail bounce message received BY Gmail.
2) received-from-gmail.txt - the mail as received FROM Gmail at the host mail account.
 

Attachments

  • gmail-bounce.txt
    4.3 KB · Views: 173
  • received-from-gmail.txt
    72 bytes · Views: 76
Same handlers permanentfail error in here, what can I do?

Hi. This is the qmail-send program at plesk.myhost.extension.
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]>:
handlers permanentfail

<[email protected]>:
handlers permanentfail
 
Hello,
Do we have some sollution for this problem?
I also have same issue.

--
Robert Magier
 
We also have reports of this problem, please update this ticket once resolved.

Thanks
 
Several of my clients were having the same problems, however, we were not able to reproduce the "handlers permanentfail" error in our offices. In one organization, the secretary could not send emails to her boss who is being redirected to an AOL account. I created several accounts with yahoo, google and hotmail but everything worked fine for us. Also, most other people could email the boss.

I found this thread, turned off Domain Keys and now everything is working fine... I would be happy to send a copy of the bounced email to any PSA admins that would like to see it, although the error is identical to calderwood's.
 
Well the email forwarding is now completely broken on one of our Plesk servers. It was clean built using 8.4 and patched to the latest version.

Another server that was upgraded from 8.3 to 8.4 still has functioning local redirects but the external redirects to servers like Gmail/Yahoo/Hotmail are still broken.

I'll attempt to send a follow-up to Sergius now to see if they've had any luck at all identifying the cause of this.

Otherwise, I'm about done with trying to live with Plesk. I'm going to be testing cPanel 11 on another machine later and their new migration scripts.
 
I can actually confirm this bug is introduced by DomainKeys. If you enable DomainKeys support for incoming or signing outgoing or both email redirects will cease to work.

You can solve this problem for now by doing the following in "Server Wide Mail Preferences":
1. Turn off "Allow signing outgoing mail" and click the OK button to save.
2. Next turn off "Verify incoming mail" and click the OK button to save.
3. SSH to root on your Plesk server and stop/start all services:
/etc/rc.d/init.d/psa stop
/etc/rc.d/init.d/psa stopall
/etc/rc.d/init.d/psa start
/etc/rc.d/init.d/psa startall

(the above paths may vary depending on which operating system you are using)

(I have to issue both start and startall on my machine otherwise DrWeb daemon, among other things, is not properly started and breaks email)

Now try using email redirects again. On my CentOS/Red Hat Linux 5 boxes this solved the problems both for internal and external redirects. But unfortunately we're now without DomainKeys support once again.

I truly do hope SWsoft will solve this flaw in their implementation ASAP.
 
I have the same problem, with a CentOS 5 Box and Lastest upgrades.

As says the last post, turning off all about DomainsKeys "fix" the problem, BUT paralles give us a candy with the improvement of DKs and it doesn't work, please try to fix it.

Now trying to not only say bad things, here something to help...

I see that each old redirect account on the upgrade momment are working fine, and all the new accounts, do not work... until I disable the option "Allow signing outgoing mail" restart all as suggested the last post and re-enable it again (I tryed it again and restart all the services are not necessary, just disable and enable again). Now all the redirects accounts are working. Is like the old acounts when I updated my panel.

So, the problem in the script for new redirects integration with DKs.

I hope this help... to keep "happy" the clients I (and you too) should disable and enable the DKs daily to keep "up to date" the redirects that some client might create.
 
Just to let you know I've heard back from Sergius:

We've fixed the issue and it will be available w/ the Plesk 8.4.1 which is expected in the end of the June.

So that's good news.
 
That is not good news. They have a fix available but refusing to make it available to the thousands of businesses suffering from the bug?!?!
 
That is not good news. They have a fix available but refusing to make it available to the thousands of businesses suffering from the bug?!?!
You are right!

Maybe they are just relaxed because the problem can be bypassed just with disable that GOOD FEATURE, so... I do not undestando it too
 
Well at least a working fix has been promised to us now. I just hope they are using the time between now and the release at the end of June to test the proposed fix thoroughly on a variety of platforms.
 
Back
Top