Posts Tagged ‘postfix’

Missing Parallels Plesk for Linux updates

Saturday, February 11th, 2012

If you’re using Parallels Plesk 9.x with Postfix as the MTA, there appears to be a bug which can stop Plesk from displaying important updates that are available, including the micro-updates which provide important bug fixes and security updates.

If you are using the Updates section of the Plesk web interface, then no error message is displayed, so it just looks like there are no updates available. However, you can also check for updates using the Parallels autoinstaller utility from the command line:

/usr/local/psa/admin/sbin/autoinstaller –check-updates

After downloading all of the .inf3 files from Parallels, this will give you a badly translated error message:

Unable to process patch config: PSA_9.5.4/plesk-patches-9.5.4-cos5-x86_64.inf3: Failed to parse the patch file at (line 34 column 13)
Group named ‘qmail’ is not exists on this system.

Despite the qmail MTA not being installed because the Postifx MTA is being used, the Plesk autoinstaller utility (which is also used by the web interface) seems to be checking for a “qmail” group. The fix for this is incredibly simple – just create an empty ‘qmail” group:

/usr/sbin/groupadd qmail

Now if you refresh the Updates section in the Plesk web interface or re-run the Parallels autoinstaller from the command line then you should now see the available updates, which you can install in the normal manner.

Preventing backscatter on aliased domains in Zimbra

Tuesday, April 5th, 2011

By default, an aliased domain in Zimbra will accept all e-mail at SMTP time and then bounce a message later if it is unable to delivering it after carrying out the aliasing. This generates backscatter, which can be abused and even lead to your mail server appearing on some blacklists. Luckily, since Zimbra 5.0.12 there has been a way to fix this; just su to the zimbra user and run:

zmlocalconfig -e postfix_enable_smtpd_policyd=yes
zmprov mcf +zimbraMtaRestriction “check_policy_service unix:private/policy”
postfix stop
postfix start

Parallels Plesk 9.5.1/9.5.2 and Greylisting

Friday, June 11th, 2010

In April’s Plesk 9.5.1 update (following on from 9.3.x – apparently Parallels can’t count so just skipped 9.4.x and 9.5.0 entirely…) they managed to seriously break one of the great Plesk 9 features for Postfix users… greylisting!

One of the big improvements when Plesk 9 was released (apart from ditching QMail!) was that it no longer relied upon unsupported third party software such as QGrey to add greylisting features. The big benefit of this was that the greylisting was tied in the with authentication of mail users, so users who authenticated to your SMTP server in order to use it as a relay automatically bypassed the greylisting filters.

The use of third party greylisting in Plesk 8.x was the source of much frustration from users who were trying to send e-mails and were getting unhelpful error messages from their e-mail clients. This puts server administrators in a difficult position; deal with the user complaints, or disable greylisting and put up with a massive increase in spam e-mail.

In Plesk 9.5.1 this feature mysteriously stopped working. At first Parallels claimed that greylisting was working as designed, but then admitted that it was a bug and they would fix it. The Plesk 9.5.2 release came and went with no fix and no word from Parallels. In the end, it was well over a month from Pleks 9.5.1 being released and the bug first being reported to a patch being available.

The fix that they have released isn’t released as a hotfix and so doesn’t show up in the normal Plesk update process either from the command line auto-installer or the Plesk web GUI’s udpate manager, nor is it applied as part of a fresh install. It’s not even on the Parallels Knowledge Base, you have to go on their forums and find it in a thread by a Parallels member of staff known as “IGorG” called “Workarounds” in the “Parallels Plesk Panel 9.5 for Linux/UNIX Suggestions and Feedback” forum.

Even once you have located the ZIP file containing the patched code and got your forum login to work long enough for you to download it without getting a “Can’t create new user ” error, Parallels have only release the fix for certain platforms (in particular, CentOS 4.x and 5.x both 32-bit and 64-bit as well as Debian 5 64-bit only) and they don’t seem to have any intention of releasing the patch for the other Linux/UNIX platforms supported by Plesk 9.x (SuSE, openSuSE, FreeBSD, Fedora, Debian 3.x & 4.x, Debian 5.x 32-bit, Ubuntu or CloudLinux).

If you are lucky enough to be on one of the supported platforms for which they have released a patch then you can download the ZIP file with the new postfix-queue files from the “official” post on the Parallels forum at http://forum.parallels.com/showpost.php?p=413387&postcount=62

Once you have copied it onto your server and extracted the contents, you should find several folders which correspond to the patched platforms (Cos4x32, Cos4x64, Cos5x32, Cos5x64 and Deb5x64), each of which has a fixed copy of the “postfix-queue” binary inside.

Back up your current postfix-queue from “/usr/lib/plesk-9.0/postfix-queue” (32-bit copies of Plesk) or “/usr/lib64/plesk-9.0/postfix-queue” (64-bit copies of Plesk) to somewhere safe and then copy the postfix-queue file from the appropriate directory over the /usr/lib/plesk-9.0/postfix-queue or /usr/lib64/plesk-9.0/postfix-queue file and restart the Postfix service.

Your authenticated users should now be able to send e-mail again without having to wait for the greylisting timers.