Saturday, March 29, 2014 9:41 PM
How to manually fix a Plesk glitch where locally generated E-Mails get lost
Author: matthias - Last modified: Monday, March 31, 2014 7:15 PM
en plesk postfix e-mail bug domain mail service mta postman
Are you using Parallels Plesk with postfix, configured a domain for which E-Mail is handled on a foreign MX host and wonder why E-Mails created on that system (e.g. through PHP form mailer scripts) vanish and won't be transported to their destination? Yes? Then read on.
Oh dear, though Parallels Plesk greatly improved in a lot of aspects over the years, there're some bugs that seem to be "built in", like being a feature rather than a bug. But: If you start googling and searching for solutions you'll find a lot of (old) discussions, all referring to more ore less the same problem but hardly any of them giving helpful hints. I'll try to provide a straight description and solution for that specific situation and Plesk bug.
Versions affected
I faced the behavior described below years ago with older Plesk versions but today struggled with it again. My currently used and affected version is Plesk Panel 11.5.30
(at least until micro-update #35).
Situation
Let's assume you configured a domain, we name it test.com, within Plesk panel to be used for e.g. website hosting. For whatever reason on initial domain setup you've chosen to activate "E-Mail service" for that domain. But you'd configure neither E-Mail addresses nor mailboxes for that domain. You probably also don't need to configure DNS for that domain because that's done elsewhere - like the whole E-Mail (MX) stuff.
Problem
E-Mails to recipients within test.com that are generated on your Plesk host won't get transported to the correct (publicly configured MX) host. Example: E-Mails generated by a PHP form mailer script sent to info@test.com get lost. You probably register some kind of log entry in /opt/psa/var/log/maillog telling you Message aborted.
Reason...
Postfix (MTA used by Plesk) is configured with entries for test.com in the virtual_domains database. That means: Before evaluating any other way of transport, the local mail transfer agent, i.e. postfix, decides to deliver this E-Mail locally. And this is deadly wrong in our case.
... and the actual Plesk Bug
First idea is of course to uncheck "Activate E-Mail Service" in your Plesk Panels configuration page for E-Mail settings (Panel path: ... / test.com / E-Mail / E-Mail Settings). And then, your next E-Mail to info@test.com generated on that host ...fails again! Here's the specific Plesk bug: postfix virtual_domains (+ virtual) database entries are never cleaned up after "E-Mail Service" was activated once for a specific domain - even if you later deactivate this option in your Plesk domain setup configuration.
Solution
Use the shell. Find the postfix database (hash) files. Search and modify the virtual_domains as well as virtual database files using postmap. Be careful, you've been warned! But things are pretty straight forward:
$ cd /var/spool/postfix/plesk
$ postmap -s virtual_domains | grep "test.com"
test.com test.com/
$ postmap -d test.com virtual_domains
Basically, that's it! When working with the Plesk Panel, be sure not to check "Activate E-Mail" for test.com again and you should be fine. Now, while next is not mandatory to restore desired behavior, you should also cleanup your virtual database defining user E-Mail alias addresses. Those were also automatically generated by Plesk on initial domain "Mail Service" setup. Check the entries, it will probably look something like this:
$ postmap -s virtual | grep "test.com"
postmaster@test.com postmaster@localhost.localdomain
root@test.com root@localhost.localdomain
mailer-daemon@test.com mailer-daemon@localhost.localdomain
anonymous@test.com anonymous@localhost.localdomain
drweb@test.com drweb@localhost.localdomain
Go, take your time and delete the unwanted entries, step by step:
$ postmap -d postmaster@test.com virtual
$ postmap -d root@test.com virtual
...
Hope that was helpful for some of you guys out there. Now I'll go and submit a bug report at Parallels.