Search results

The files mentioned contained (partly among others) the main system domain, like test.de After the update, the <.de> was vanished and only the second level part <test> remained causing several malfunctions.

Here, I found that 9.3.0 seems to created erronous entries in /var/qmail/control me locals rcpthost by removing the top-level-domain part from the main system domain. It caused 17000 mails as you got until I found the reason and all its occurances.

I realized that manually by inserting a script into the qmail handling (requires some work on the console like linking of files, ...)

Thanks for the details... I finally skipped the backup way and used the migration manager (although that still was a lot of hassle). It looks as the pre9_convert converts not fully (or it should clearly raise the problems identified during the conversion to get them fixed). The error messages...

Try the migration manager. For a Linux -> Linux migration, it was the only tool which could (although with a lot of hassle) migrate the data.

And this problem still persists when migrating to Plesk 9.2.2 Any chance to get it fixed?

During the recent migration from 8.6 to 9.2.2 on different machine, I saw again what I experienced during all the restores since using Plesk. The users of the mailman mailing lists are entered there as new users and the creation of "welcome" messages is not stopped. So even during first...

For the migration process, you have to allow the login of a root user via ssh. I normally also use "PermitRootLogin No" for ssh, but for the migration, I had to allow that.

Upgrades of Plesk (like 8.6 to 9.x) are known to cause a lot of work and problems, possible server outages and so on. As as migration to a new machine was planned anyway, I decided to handle this (hardware and software migration including OS migration to OpenSuse 11) in one step. The setup...

I tried it with the Migration manager here (my complete backup contains approx. 15 GB). But the migration fails and the explanation is not really helpful (it simply says nothing).

@NikolayM Did you find a way to solve the problem? I have the same problem, the backup from 8.6 is converted and recognized by 9.2.2, but a restore fails and the log contains no real sufficient answer.

While moving my domains to another server, the Plesk configuration and data was moved using pleskbackup and pleskrestore. When checking my mailing lists, I noticed, that configuration settings (like the privacy settings) were lost. Additionally, Plesk does not prevent the creation of...

@intosh Again, read and understand how the submission port works... after reading and understanding tell your users... if you did not understand, got to the beginning and start again.

@intosh It seems to be very difficult to get familiar with software and how this software is working as well as understanding how the smtp protocol works. Plesk uses Qmail for mail processing. Qmail as such does not support DNS blacklisting. SMTP Authentication is a part of the SMTP...

You should perhaps have a closer look on HOW DNS blacklists work... to ensure speed, the list is checked first. That's why eg. the submission port exists. And again, although not satisfied with Plesk at all, for this, Plesk cannot be blamed.

You cannot solve this problem as such and it is NOT a problem of Plesk. The check against the dns blacklist is done at the first connection attempt of the sender. At that time, no authentication happened, so it cannot be determined whether the user can authenticate himself or not. Tell...

At least I managed to get the PCP running again. I discovered, that /usr/local/psa/admin/conf/httpsd.conf had only 1 byte. The error_log showed a port conflict (that's why I tried to check the port configured). I restored an old backup saved by PSA and httpsdctl could start the PSA...

One solution... as swsoft obvious and as usual does NOT respond: I restored /usr/lib/courier-imap/authlib/authpsa from my backup (plesk 8.3.0). which has here (Suse 10.1) 80160 bytes instead of 37736 of the new version and the IMAP/POP3 problem is gone. Either the database update...

The problem was obviously a bug of PLESK, with the newest update it is gone. I would REALLY appreciate, if SWSOFT just would confirm such a bug here. This would save a lot of guessing and searching. But it seems that support and reaction to user requests (hint, they paid for it) is not...

I have the same problem with Plesk 8.1.1 and Suse 9. Some more things... even replacing httpsd.pem with proper right settings did not solve the problem when logging into the CP (after restarting psa of course). Moreover, when trying to install the current cert into the CP, I notice, that...