Applicable to:
- Plesk for Linux
Symptoms
-
Email messages and mailing list deliveries are delayed
-
One of the following errors might appear in
/var/log/maillogfile:CONFIG_TEXT: handlers_stderr: DEFER
DEFER during call 'grey' handler
Message aborted.
milter-reject: DATA from mail.example.com[203.0.113.2]: 451 4.7.1 Service unavailable - try again later; from=<jdoe@example.com> to=<jsmith@example.org> proto=ESMTP helo=<mail.example.com>CONFIG_TEXT: greylisting filter[10489]: Starting greylisting filter...
/usr/lib64/plesk-9.0/psa-pc-remote[8641]: handlers_stderr: REJECT
/usr/lib64/plesk-9.0/psa-pc-remote[8641]: REJECT during call 'grey' handler
/usr/lib64/plesk-9.0/psa-pc-remote[8641]: Message aborted.
postfix/smtpd[10450]: reply: SMFIR_REJECT data 0 bytes
postfix/smtpd[10450]: E612613C0057: milter-reject: DATA from unknown[203.0.113.2]: 550 5.7.1 Command rejected; from=<jdoe@example.com> to=<jsmith@example.org> proto=ESMTP helo=<mail.example.com> -
Mailing list deliveries are delayed and the following error is shown in
/var/log/maillogfile:CONFIG_TEXT: postfix/smtpd[1598278]: 85AB012F841: milter-reject: DATA from localhost[127.0.0.1]: 451 4.7.1 Service unavailable - try again later; from=<mailinglist-bounces@example.com> to=<jsmith@example.org> proto=ESMTP helo=<mail.example.com>
And the following error is shown in
/var/log/mailman/smtp-failurefile:CONFIG_TEXT: (2430) delivery to jsmith@example.org failed with code 451: 4.7.1 Service unavailable - try again later
Cause
This is expected the behavior of Greylisting.
Greylisting works as follows: the first message is rejected, and the next message sent from the same address (sender server IP address and 'From:') will be accepted after a certain length of time passes.
After the first email is rejected, the sender's address is added to the Greylisting database. The information is stored there for an expiration time interval.
For the message to be accepted, the grey interval must complete. If the message was sent before the grey interval has passed, the penalty interval is added.
Resolution
To prevent a delay, perform one of the following actions:
-
Reduce the grey interval according to the following KB article: How to configure Greylisting?
-
Go to Plesk > Tools & Settings > Spam Filter Settings > White List and add the required mailbox, domain or pattern to the white-listed senders and their emails will be accepted without passing through the greylisting and SpamAssassin.
-
Adding an email address to the whitelist:
jdoe@example.com -
Adding all emails sent from a specific domain to the whitelist:
*@example.com
Note: In case an email sent to a mailing list is delayed, it is required to add the domain from the mailing list address in the white list.
-
-
Disable Greylisting spam protection on the whole server by unchecking Switch on server-wide greylisting spam protection in from Plesk > Tools & Settings > Spam Filter Settings
Warning: This change reduces the protection from spam.
Comments
8 comments
As it seems, greylisting also happens for mails submitted internally or sent (authenticated) via Ports 587 / 465. This should not be the case?
Hi b_p,
By default, it is no matter which port is used. Greylisting checks received messages despite the way they were delivered. It can filter emails sent internally or via 587/465 ports.
Emails are processed during the SMTP session and there is checked whether the client has previously connected recently.
Hi Mikhail Shport the problem is: it also happens when you have forwarding mail addresses (e.g. you can an external mail (after the greylisting timeout) and this should now automatically be forwarded to another address. As the original sending client already has passed the greylisting barrier, checking this again does not make sense.
In addition, if greylisting would be properly implemented (e.g. using postgrey), it is clearly possible (https://rimuhosting.com/knowledgebase/linux/mail/greylisting%20with%20postgrey) and desired that authenticated users (who connect through whichever port but DO authenticate) are excluded from greylisting. Not trusting your own users when they try to send (authenticated) mails, is not the proper way...
Hi b_p,
If one of the mailboxes is compromised or there is malware on the server it is a good idea to check local messages as well.
Emails are processed by greylisting over SMTP connections. When a mail address forwards a message it creates a new connection because the sender changes.
If it seems greylisting works improperly on the server I suggest you submit a request to the support in order to check it further.
Hi Mikhail Shport as the number of outgoing mails can be limited anyway (# of mails per hour), this does not make sense. In addition, since graylisting allows a client to connect after a certain time, you would not block anything locally but only delay sending these mails for a few minutes as they are still in the queue anyway. Thus, please change the standard behavior. Also, can you please check with your colleagues - this has not happened before so there must have been an intentional change?
b_p Hi! Could you please clarify whenever you have Plesk Email Security installed?
Hi Anton Maslov I only use Dr. Web, not the new Email Security package.
Hi Mikhail Shport Anton Maslov any update from this?
Here is another example configuration from a different tool https://rimuhosting.com/knowledgebase/linux/mail/greylisting%20with%20postgrey. If you have a look at the comments, they explicitly state that greylisting should only happen if no authentication has taken place.
Please sign in to leave a comment.