LinuxWebLog.com

On Debian with Plesk-8.2 installed, /etc/inetd.conf show up with:

Essentially, when the SMTP connection is made, rblsmtpd is handed the connection and does its DNSBL checking. It’s then responsible for either executing the next program (relaylock) if there’s no match, or handles the connection itself if it does find a match. Thus smtp authentication never takes place if your IP is listed in PBL.

On checking Parallels Forum, I came across this post, which suggested:

If you use an dnsrbl in Plesk that lists the IP of someone trying to connect to your server to send email then they will not be able to use your server for smtp on port 25. The dnsrbl will block their attempts. This is normal and expected behaviour in Plesk.

The instructions you read about using authenticated smtp to get around the problem do not apply to the default installation of Plesk (and other similar setups). The idea of the instructions you read is that by using authenticated smtp you will bypass the dnsrbl, and therefore will not be blocked. This does not happen with the default installation of Plesk so the instructions won't work (they are rather simplistic).

The solution in Plesk 8.4 is a simple one. Enable the "submission" option in Plesk, ask your customers to change to port 587 from port 25 in their email clients and require them to use smtp authentication (remember to open up your firewall for port 587 too). This basically creates a second smtp instance listening on port 587 instead of port 25, does not have any dnsrbl blocking and REQUIRES users to use smtp authentication in order to be able to use it. No spam will come via that port because a) server to server email transfer happens on port 25 and b) it requires authentication.

(A similar solution will work in earlier versions of Plesk but rather than ticking a box in the control panel to get it to happen you have to copy a single file and edit two lines in it, but it works just as well and basically does the same thing)

The other option you can go for is to install spamdyke (search the forum for step by step instructions) which does bypass all dnsrbls when smtp authentication takes place. Note that when you use spamdyke you will not be able to use pop-before-relay authentication, and that you set up dnsrbls within spamdyke's configuration files, not via Plesk. spamdyke does add a whole plethora of additional anti-spam measures, however, and it is well worth installing if you don't need pop-before-relay.

Since version of Plesk is older, I put in the below lines in /etc/inetd.conf and restarted inetd.

Now on using the port 587 instead of port 25, users are able to autheticate and send email via the SMTP/Submission server.

To receive local root email to an externally monitored email address:

• Login to plesk control panel and set the admin contact email address for the server which should update "/var/qmail/alias/.qmail-root" file and add an alias for root.
  
• Either add the hostname (FQDN) to the qmail control locals file or to the virtualdomains file located in "/var/qmail/control/".
  
• Also add the hostname (FQDN) to the "/var/qmail/control/rcpthosts" file if not already present so local mails get delivered.
  
• Restart inetd and qmail:
  
  /etc/init.d/inetd restart
/etc/init.d/qmail restart
• Check with:
  
  /var/qmail/bin/qmail-showctl

  This should show:
  

  ...
locals:
...
Messages for host.domain.tl are delivered locally.
...
rcpthosts:
...
SMTP clients may send messages to recipients at host.domain.tld.
...

I have recently had to restore plesk from an offsite filesystem backup due to disk drive failure and loss of data. Below are notes for reference and the corresponding list of important folder/files to be backed up for a successful restore.

It helps if you are restoring sites to the same version of OS and Plesk Control Panel, so reload the OS and version of Plesk as was running prior to the data loss.

SYSTEM:

1. Merge "/etc/passwd", "/etc/group" and "/etc/shadow" for domain user accounts.
2. Bring up all IP aliases:

Note: Keep backup of "/etc".

MYSQL:

1. Reset Plesk "admin" user password to old one.
2. Copy over "/etc/mysql/debian.conf".
3. Import all mysql databases:

Export:

Import:

4. Restart mysql.

Note: Keep backup of "/var/lib/mysql" and "/var/log/mysql" (if incase database is corrupted and need to be restored using binary log files).

PLESK:

1. Reload ssl certificates from "/opt/psa/var/certificates/" or reinstall the certs via the control panel.
2. Restore/Merge phpmyadmin config "/opt/psa/admin/htdocs/domains/databases/phpMyAdmin/libraries/config.default.php", the below variables in particular:

Note: Keep backup of "/opt/psa".

WEB:

1. Restore "conf.d/zz010_psa_httpd.conf".
2. Sync "/var/www/vhosts".
3. Check for psaserv and psacln folder permissions on "/var/www/vhosts/domains".

Note: Keep backup of "/var/www/vhosts".

DNS:
1. Copy over "/var/named/run-root/etc/named.conf".
2. Copy over "/var/named/run-root/var".
3. Set the permissions correct:

Note: Keep backup of "/var/named".

MAIL:

1. Sync "/var/qmail".

Note: Keep backup of "/var/qmail".

I was not receiving mails from a particular email address. The MX records checked out fine. The mail server was not in any of the DNSBL list I was subscribed to. There was nothing in the logs that mentioned that there was any emails coming in from the user. However, it did have a lot of relaylocks for the mail servers IP address.

Digging in some more, I found a similar issue discussed at theplanet forum where the issue was caused due to conflict of timeouts and auth packets being dropped instead by the sender mail server, so I adjusted qmail timeout which seemed to push the conversation between the MTAs forward and the emails are now being accepted.

I changed the default timeout from 30 seconds to 15 seconds by editing the /etc/inetd and adding -t15 as below.

If you're short of IP addresses and hosting multiple domains on a single IP requiring SSL connection to all domains, then a good solution would be to get the Multi-Domain certificate from Comodo, which is a single certificate containing more than one domain name, and that certificate is for a single server installation.

However, the use of Host Headers (which is how you can use a single IP for more than one SSL enabled domain) is not recommended for E-Commerce sites.

The multi-domain certificate can only be purchased from one of the Comodo resellers, or can apply to become one yourself.

To order the certs, you will need to first generate a Certificate Signing Request Key. This is easily done via Plesk admin UI.

1. Login to the Plesk Control Panel.
   
2. From the left hand menu, select 'Server'.
   
3. Click on 'Certificates'.
   
4. Click on the 'Add New Certificate' item.
   
5. Fill out the information on the page. All items noted by red asterisks must be filled in
   
6. Press the 'Request' button.
   
7. You will then be returned to the Certificates menu. From the list at the bottom of the page, click on the certificate name that you just created. Mid-way down the page, there is a box. Copy the content of this box labelled 'CSR'.
   
8. Paste the CSR into the order screen when purchasing the SSL certificate.

Shortly after ordering, the SSL certificate is emailed to you zipped along with the below CA certs:

1. AddTrustExternalCARoot.crt
   
2. PositiveSSLCA.crt
   
3. UTNAddTrustServerCA.crt

The CA certs need to be concatenated and uploaded to Plesk as one single certificate and should follow the same order.

Those files are available for download from Comodo's support site as well.

The order you place the contents of those files into a new file is important, and should be followed as outlined above. No blank lines should be added between the certificate contents when you copy the contents of the existing CA certs into a new file. You then provide this new file to Plesk when it asks for the CA Certificate.

In order to install the certificate, go back to the Certificate area in Plesk and upload or copy/paste the certs into the relevant areas.

Return to the Server Page and go to the IP address section. Click on the relevant IP address and apply the newly installed certificate.

Package mpack is required in order to extract the backup contents.

The result is a set of tar and sql files that contain domains' directories and databases. Untar the directory as needed.

For example, to restore the httpdocs folder for the DOMAIN.TLD domain:

Reference:

How to extract web files, databases etc from Plesk backup manually?

1. Edit "/var/qmail/mailnames/{domain.tld}/.qmail-default"
   
2. Remove any lines in the file and add the pipe to file:
   
   | /var/www/vhosts/{domain.tld}/file.php
3. Change the file permission to be executable and owned by the correct user/group of the site, specially if you are executing under safe_mode.
   
   $ chmod 755 /var/www/vhosts/{domain.tld}/file.php
4. Check to make sure that "/var/qmail/control/rejectnonexist" does not have the corresponding domain listed there.
   
5. Restart qmail.

Create a "vhost.conf" file in "/var/www/vhosts/<DOMAIN.TLD>/conf/"

Rebuild the domain configs for the particular host via:

or rebuild all via: