virtual.db workaround code

[onsightdata]

Sure nice to see parellels staff is taking an active role in reading the forums for version 9 and posting fixes ( I have not seen this happen in previous releases).

I would like to see a sticky topic that is maybe locked at the top that has the issues and the links to the hotfixes or the howto fix . That way its easy to find bugs and the fixes for users.

 

[Brujo]

Absolutely right.
The root of problem is in mchk utility which is setting up the aliases by mistake (for postfix MTA only).
mchk is called automatically during upgrade and breaks aliases.

If you use postfix mta:
To fix the problem you can try to apply the following steps to your 9.0.1 installation:
1) download mailsrv_entities_dump utility for your OS and arch from ftp://download1.parallels.net/Plesk/Hotfix/PleskUnix/9.0.1/149248/
2) put it into the /usr/lib/plesk-9.0/ directory
3) run /usr/local/psa/admin/sbin/mchk

mailsrv_entities_dump is a part of mchk which is responsible for mail aliases.

@dash, what should the fix do? i used it but i have still entrys with @localhost.localdomain

Brujo

 

[mirage]

Hi all -

I'm affected by this also - at least by the part where postfix insists on delivering to local domains, even though mailservice is disabled for that domain AND I'm handling the MX records. In fact I host NO email on this machine.

Basically all webforms get rejected. I'm bouncing to my own address and then hand forward to clients, but I need a better way....

Wondering if there's a partial workaround for this. How can I force postfix to ignore local domains for delivery alltogether until such time that Parallels provides a fix?

Thanks much in advance.

 

[onsightdata]

Did you read the postings in this topic? There is a hotfix from parellels staff plus a few other postings on other ways to fix it. Did you even try them?

 

[Brujo]

i downloaded the hotfix for my OS and placed it as described above from dash and did the mchk, but i have still the wrong entrys with @localhost.local.domain

Afterwards i created a new domain to see if something have changed with the fix and now "only" the following entrys was automatically was created:

postmap -s /var/spool/postfix/plesk/virtual |grep dummy
[email protected] [email protected]ldomain
[email protected] [email protected]ldomain
[email protected] [email protected]ldomain
[email protected] [email protected]ldomain

if i compare this situation with my postings before http://forum.parallels.com/showthread.php?t=85605&highlight=localdomain some of the wrong entrys are now not more automatically created like info, support, abuse....

additional wrong entry was created after i just added a mailinglist to the testdomain

[email protected] [email protected]ldomain

@dash so i tryed it as you proposed, but sorry to say for me it seems still buggy and it is just a 50% try of fix it, and of course i did send a bugreport end of December to parrallel and got 3 weeks later the answer a known issue which will be fixed with 9.0.1

Brujo

 

[mirage]

Did you read the postings in this topic? There is a hotfix from parellels staff plus a few other postings on other ways to fix it. Did you even try them?

Yes, I did download the hotfix and applied it. But that didn't change anything in my case. And I wasn't exactly suffering from all the problems the OP attempts to patch with his script. And I'm somewhat reluctant to run scripts unless they are from an official source (Parallels) or I fully understand what they do. So before yelling, please realize that I'm first trying to understand the issue.

Again the hotifx made no difference. But I tried something else:

For the domains in question, I had the catchall email address set (also hosted externally, with domain/site hosted locally) and that was getting delivered.

So I then instead set the catchall handling to 'reject'. This caused the message to be delivered externally to the locally hosted domain in question.

Perhaps this is how it's supposed to work, since the email address really doesn't exist locally. But it seem odd that the reject handling would act different than a catch all.

Cheers,
j

 

[dash]

@dash, what should the fix do? i used it but i have still entrys with @localhost.localdomain

Brujo

Let me explain:

1. you have a domain in Parallels Panel: domain.com
2. You have mailname [email protected] on this domain (or support@, abuse@, etc). mail is delivered correctly to [email protected] mailbox.
3. Now you call mchk or switch from qmail to postfix or run Plesk upgrade
mchk restores standard alias [email protected] : [email protected]ldomain in virtual.db
Ups... since that moment mail is no longer delivered to [email protected] mailbox.
Exactly this behavior was fixed - now mchk will not restore (info|abuse, etc)@localhost.localdomain if such mailname already exists in Plesk

 

[ramuva]

Yes, I would consider issue fixed too.
As for other localhost.localdomain aliases - since you (service provider) should get complaints coming to postmaster, root, etc., it is reasonable that service provider is receiving them, not the client.

 

[Brujo]

@dash, thanks for the answer and yes as i wrote above i can confirm the fix solve the issue with info, abuse etc.

hopefully you get ride also about the others

Brujo

 

[GravuTrad]

fix applied, but emails sent are always never received...

 

[Paebbels]

removing localhost.localdomain from virtual

hi,

I've created 3 event in Plesk (email add, edit, remove) with the following command:

postmap -s /var/spool/postfix/plesk/virtual | grep -v localdomain > /var/spool/postfix/plesk/virtual && postmap /var/spool/postfix/plesk/virtual

 

[ramuva]

There is small bug left in this regeneration thing.
All entries in vmailbox, +extra aliases in virtual are generated even if mail support for domain is turned off. There is no entry in virtual_domains, but that is not enough.

Problem usually manifests when mail domain was hosted in plesk enviroment but was moved elsewhere. WWW hosting is still in place. In this case disabling mail support for this domain is not sufficient, all mailboxes have to be deleted too.
(otherwise mail will be tried to delivered into local domain and will be bounced/rejected depending on configuration)

In last case I still won't be able to send emails addressed for build-in aliases from external domain from my own domain (info@, postmaster@, etc. mail addresses will be intercepted and tried to deliver locally instead of remote location).

 

[kanada]

Hello,

there is still something wrong with postfix aliases in psa. I have couple domains which served only DNS on psa.
Example:

domainX.com is located in psa IP: 1.1.1.1 (only DNS management). MX record for this domain is pointed to other server, IP: 2.2.2.2.
When i send mail from local domainY.com to [email protected] postfix is trying to deliver it localy to [email protected]omain which is completly wrong of course.
Alias [email protected] to [email protected]omain is located in db file /var/spool/postfix/plesk/virtual, but domainX.com is'nt a local domain!

Please fix this asap.

Regards,
Alex

 

[FrankR]

I think the bug is still alive

I've got the [email protected]omain problem in my Plesk 9.2.2.

 

[FrankR]

The bug is still alive. I have the [email protected]omain problem on my plesk 9.2.2

 

[homerj]

I can confirm. Bug still present in 9.2.1 and customers are complaining...

 

[Wolltronic]

Finally found this thread - thanks to dash!
But actually, the problem still exists with Plesk 10.2 (Ubuntu 10.04 LTS) - didn't find any hints or hotfix for this!

# postalias -s /var/spool/postfix/plesk/virtual |grep 'mydomain.tld'|grep local
[email protected]: [email protected]omain
[email protected]: [email protected]omain
[email protected]: [email protected]omain
[email protected]: [email protected]omain
[email protected]: [email protected]omain
[email protected]: [email protected]omain

Okay, there is no more <info@...> entry - but we receive a lot of spam to <root@...> and <postmaster@...> at client-domains, which should simply be rejected!

And my approach to read local root-mails was adding to /etc/aliases :
root: [email protected]
and adding a mail acount <[email protected]> -
by that, the root entry was removed from virtual.db
Same with <[email protected]> when I first added and then removed the mail account in the Panel.
This worked fine for some weeks, but now it apeared again.

Worked around by using another account <[email protected]>, but this was a lot of work, just because of this crazy behaviour of mchk, which even seems not to be documented! And I don't like this <[email protected]> spam!

Any idea? Thanks!