Issue Postfix stopped working for domains hosted on server after upgrading to 18.0.34

[exit15]

System Plesk Obsidian v18.0.34_build1800210305.11 os_Ubuntu 18.04
Note, we are only using the server to send out emails, individual email accounts are managed by google g suite

Issue: we are not getting emails sent by the system to any domain user (order confirmation, etc). Emails sent to external domains gmail.com, yahoo.com etc are ok.

Here's a sequence from maillog of an email sent to a "[email protected]" succeeding and the email sent to the store owner "[email protected]" failing - status=bounced (User unknown in virtual alias table)

Mar 11 17:01:01 Exit15 postfix/smtp[12579]: 8689B80EE7: to=<[email protected]>, relay=mta6.am0.yahoodns.net[67.195.228.94]:25, delay=1.3, delays=0.02/0.01/0.51/0.75, dsn=2.0.0, status=sent (250 ok dirdel)
Mar 11 17:01:01 wellness postfix/qmgr[1515]: 8689B80EE7: removed
Mar 11 17:10:05 wellness check-quota[12868]: Starting the check-quota filter...
Mar 11 17:10:05 wellness plesk sendmail[12867]: handlers_stderr: SKIP
Mar 11 17:10:05 wellness plesk sendmail[12867]: SKIP during call 'check-quota' handler
Mar 11 17:10:05 wellness postfix/pickup[1514]: E00A480EE7: uid=10002 from=<[email protected]>
Mar 11 17:10:05 wellness check-quota[12879]: Starting the check-quota filter...
Mar 11 17:10:05 wellness postfix/cleanup[12874]: E00A480EE7: message-id=<[email protected]>
Mar 11 17:10:05 wellness postfix/qmgr[1515]: E00A480EE7: from=<[email protected]>, size=915, nrcpt=1 (queue active)
Mar 11 17:10:05 wellness plesk sendmail[12878]: handlers_stderr: SKIP
Mar 11 17:10:05 wellness plesk sendmail[12878]: SKIP during call 'check-quota' handler
Mar 11 17:10:05 wellness postfix/pickup[1514]: E89F780EE8: uid=10002 from=<[email protected]>
Mar 11 17:10:05 wellness postfix/cleanup[12874]: E89F780EE8: message-id=<[email protected][email protected]>
Mar 11 17:10:05 wellness postfix/qmgr[1515]: E89F780EE8: from=<[email protected]>, size=913, nrcpt=1 (queue active)
Mar 11 17:10:05 wellness postfix/error[12888]: E89F780EE8: to=<>, relay=none, delay=0.02, delays=0/0.01/0/0.01, dsn=5.1.1, status=bounced (User unknown in virtual alias table)

 

[exit15]

thanks for the help

 

[learning_curve]

It looks like a local misconfiguration somewhere to be fair... We're using Ubuntu 20.04.2 LTS, but we've had no issues at all with the Obsidian 18.0.34 upgrade.
If you search online, especially in serverfault.com and others just like it, you'll see plenty of threads that commence with: "...User unknown in virtual alias table..." etc or, could you not just raise a support ticket instead (quick & easy) if you were not confident with any of those findings / results / fixes that you may find?

 

[exit15]

Thanks NS -- problem solved for now - sheer luck.
The issue was the the Plesk Panel host name was the same as one of the hosted domains. For some reason after the upgrade, and only after the upgrade, it refused to send emails to that domain or it was looking for email users on the server which is not used for email services.
Finally I changed the host name in the admin /plesk/server/preferences/ to some other domain and it started working again.

So maybe it is a bug, not a misconfiguration??

My conclusion has to be that if you choose to name your server as one of the hosted domains, and that same domain does not use the local email service, it will fail to send emails to self. I have another server (alas running on CentOS) that did not go though the upgrade yet, it is too using the local domain as the host name, lets see if it will fail when that upgrade goes through.

 

[weltonw]

It looks like many users have having Postfix issues with .34

 

[learning_curve]

The issue was the the Plesk Panel host name was the same as one of the hosted domains. For some reason after the upgrade, and only after the upgrade, it refused to send emails to that domain or it was looking for email users on the server which is not used for email services.

Good spot. We don't have that ^^ specific configuration, which presumably is why we're unaffected.

Finally I changed the host name in the admin /plesk/server/preferences/ to some other domain and it started working again.
So maybe it is a bug, not a misconfiguration??

Yes, could well be. Unless, there's a 'hidden' Plesk requirement somewhere... that IF the server's full host name IS a hosted domain name, then it MUST use the local mail service, but that seems very unlikley?

My conclusion has to be that if you choose to name your server as one of the hosted domains, and that same domain does not use the local email service, it will fail to send emails to self. I have another server (alas running on CentOS) that did not go though the upgrade yet, it is too using the local domain as the host name, lets see if it will fail when that upgrade goes through.

That's a logical conclusion and your CentOS server upgrade, could be your proof of concept.
Will be interesting. Will you be posting the result?

It looks like many users have having Postfix issues with .34

Yes, have seen some of those e.g. THIS ONE although the context looks slightly different?
In ^^ that case the answer / fix shown in post #22 was / is the setup in our config anyway, so again (could just be pure luck!) we're unaffected.

 

[weltonw]

Good spot. We don't have that ^^ specific configuration, which presumably is why we're unaffected.

Yes, could well be. Unless, there's a 'hidden' Plesk requirement somewhere... that IF the server's full host name IS a hosted domain name, then it MUST use the local mail service, but that seems very unlikley?

That's a logical conclusion and your CentOS server upgrade, could be your proof of concept.
Will be interesting. Will you be posting the result?

Yes, have seen some of those e.g. THIS ONE although the context looks slightly different?
In ^^ that case the answer / fix shown in post #22 was / is the setup in our config anyway, so again (could just be pure luck!) we're unaffected.

That makes sense. I'm really curious is Plesk has been seeing similar issues internally/on tickets. Would love to hear from them.

Haven't seen any issues on the staging server I upgraded to .34, but our PF conf basically deletes most of what Plesk uses