I recently debugged a mail delivery issue between a Plesk 9.2 server running Qmail and 3rd party ‘sending’ servers. In short, Qmail was not accepting email and was issuing a ” 451 qq trouble in home directory (#4.3.0) (in reply to end of DATA command)” error. Mail was then being diverted to a backup mx server (running Postfix) and being held until the Qmail server eventually accepted mail or the postqueue was forced.
The following is the receive error from the Plesk 9.2 server, running Qmail:
Jul 14 09:44:50 vh qmail-queue-handlers: call_handlers: call executable = '/usr/local/psa/handlers/info/05-grey-vvIjta/executable'
Jul 14 09:44:50 vh greylisting filter: Starting greylisting filter...Jul 14 09:44:50 vh qmail-queue-handlers: handlers_stderr: DEFER
Jul 14 09:44:50 vh qmail-queue-handlers: call_handlers: DEFER during call '/usr/local/psa/handlers/info/05-grey-vvIjta/executable' handler
Jul 14 09:44:50 vh qmail-queue-handlers: call_handlers: stop callhandlers from dir '/usr/local/psa/handlers/before-queue/global'
The backup MX server would list:
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient-------
35412AE80F9Ã‚Â Ã‚Â Ã‚Â Ã‚Â 1252 Mon Jul 13 21:41:04Ã‚Â [email protected]
(host vh.myserver.net[22.214.171.124] said: 451 qq trouble in home directory (#4.3.0) (in reply to end of DATA command))
As the undeliverable error on mail being sent to the Plesk server.
After much research and testing, it became apparent that Plesk’s grey listing was incorrectly flagging the sending server as a spam source and was applying Grey Listing parameters to the inbound messages.
Greylisting is a method of defending e-mail users against spam. A mail transfer agent (MTA) using greylisting will “temporarily reject” any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again and the email is accepted. If the mail is from a spammer it will probably not be retried since a spammer goes through thousands of email addresses and cannot afford the time delay to retry.
Whilst grey listing is a logical spam counter measure, it can cause major problems when a backup mail server is attempting to relay mail to a primary (or lower preferenced) server for a specific mail domain.
In our environment, the best solution was to disable Grey Listing completely as we already have a perimeter spam filtering solution in place.
This command will disable Plesk’s built in grey listing:
# /usr/local/psa/bin/grey_listing --update-server -status off
A detailed outline of Plesk’s Grey Listing implementation (grey_listing) can be found here.
Please Note: If you are utilizing Plesk’s build in spam filtering options, do not disable grey_listing. Instead, adjust expire and penalty options to better suit your configuration and, if n/usr/local/psa/bin/grey_listingecessary, white list mail from your backup MX server. See the Plesk technical documentation for specific configuration.
5 Replies to “Plesk Grey Listing Problems”
Yes! This worked perfectly. Why does greylist do this in the first place?
Excellent. Grey listing went wrong after the Plesk upgrade to 9.2.3 so many thanks for supplying the answer.
I disable my grey_listing (Plesk 9.3.0) and worked perfectly, but now all my webmail do not work. When i acess webmail page open server default page. Do you know why?
Disabling grey_listing and webmail not working are likely un-related issues.
1. Have you checked your DNS zone to make sure that the webmail.
. entires are in place?
2. Have you confirmed that webmail is enabled for the domain, under the mail configuration (Plesk)
3. Have you manually removed / re-added the webmail sub-domain and ran “/usr/local/psa/admin/sbin/websrvmng -a” to apply?
Comments are closed.