• Please be aware: Kaspersky Anti-Virus has been deprecated
    With the upgrade to Plesk Obsidian 18.0.64, "Kaspersky Anti-Virus for Servers" will be automatically removed from the servers it is installed on. We recommend that you migrate to Sophos Anti-Virus for Servers.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Grey listing question

gregconway

Basic Pleskian
Hi,

I have recently enabled greylisting on four of our Plesk servers, and on the whole it's helped to significantly reduce the amount of spam received by our end users.

Could somebody please confirm whether greylisting looks at just hostnames or IP addresses as well?

We have had issues with delayed mail and the only possible reason I can see is that the mail is being retried from various different mail server IPs that use the same hostname.

Thanks,

Greg.
 
Further to this we do seem to be having some problems today, whereas previously it had all worked fine. Separately from my initial problem (above but I didn't really explain in any details) I have new issues today.

To get around the fact that Microsoft and Amazon (for example) use various different mail servers we have whitelisted these domains as follows -

White domains patterns list:
*.microsoft.com
*.outbound.protection.outlook.com
*.smtp-out.eu-west-1.amazonses.com

And this worked initially (for the past week) but today mail is failing as follows -

postfix/smtpd[29210]: 2881489E274B: milter-reject: DATA from bay004-omc2s1.hotmail.com[65.54.190.76]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<BAY004-OMC2S1.hotmail.com>

So I tried whitelisting account.microsoft.com as follows -

White domains patterns list:
account.microsoft.com

But the mail was still rejected. So I am not sure what to do from here - any ideas why the whitelisting isn't working for me?
 
Any thoughts anybody?

Unless I have mis-understood the whitelisting in some way it seems it simply doesn't work.
 
Is there really nobody that has any opinion or answer for this? I am unable to call Odin, use the web chat or raise a support ticket without paying $149 for a support ticket. What other options do I have? Thanks.
 
Thank you for answering my thread. I apologise - I was looking at the wrong product. Before I spend this money could you confirm that this money will be refunded if it turns out that the greylisting within plesk doesn't actually work?
(From the "buy support" page - If the incident you submit turns out to be a bug not previously documented in our Knowledge Base, we will either credit an incident back to your account for those customers who have a support account, or provide a refund.)
To get back to the actual issue... I made various purchases on Ebay last night (first time since I introduced the greylisting) and none of the emails have arrived at all. I've checked the logs and it seems every single email from ebay is being bounced - nothing is being delivered. Does greylisting actually work correctly for anybody?!
Actually I've just spoken with another user on this server who is a regular Ebay user and having been through their emails they are receiving IPNs from PayPal but they are not receiving messages from Ebay.
I would very much appreciate hearing from anybody else who has enabled greylisting!
 
Any thoughts on this? I'm stuck between a rock and a hard place here. At present nobody on our servers can received email from Ebay - it's only a matter of time before somebody notices and complains. But if I switch greylisting off then all the users will return to a barrage of spam, which I'm sure they won't be happy with after a few weeks of relatively spam-free email!
Igor could you confirm the question in my previous post?
Anybody... any thoughts or comments welcomed here!
Thanks.
 
Hi gregconway,

could you please post as well the output of

/usr/local/psa/bin/grey_listing --info-server

for further investigations?

It would help as well to see your configuration files and additional errors/issues from your mail.log.
 
Hi UFHH01,

Thanks for the response. This is very well timed as we are at this time looking at another related issue. We have whitelisted *.outbound.protection.outlook.com but this email is being rejected time after time -

Dec 1 15:59:26 postfix/smtpd[6287]: 5468F114012B: milter-reject: DATA from mail-am1on0124.outbound.protection.outlook.com[157.56.112.124]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
Dec 1 16:14:32 postfix/smtpd[30761]: 4372A11400DF: milter-reject: DATA from mail-db3on0119.outbound.protection.outlook.com[157.55.234.119]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
Dec 1 16:29:36 postfix/smtpd[14501]: B9265114012B: milter-reject: DATA from mail-db3on0129.outbound.protection.outlook.com[157.55.234.129]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
Dec 1 16:44:39 postfix/smtpd[21351]: AED791140149: milter-reject: DATA from mail-db3on0111.outbound.protection.outlook.com[157.55.234.111]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
Dec 1 16:48:21 postfix/smtpd[21361]: 7FAE911400DF: milter-reject: DATA from mail-am1on0128.outbound.protection.outlook.com[157.56.112.128]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
Dec 1 16:59:42 postfix/smtpd[18166]: 8D914114013C: milter-reject: DATA from mail-db3on0137.outbound.protection.outlook.com[157.55.234.137]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
Dec 1 17:03:26 postfix/smtpd[14501]: 15FC1114012B: milter-reject: DATA from mail-am1on0136.outbound.protection.outlook.com[157.56.112.136]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
Dec 1 17:14:44 postfix/smtpd[21361]: ADA7E1140147: milter-reject: DATA from mail-am1on0116.outbound.protection.outlook.com[157.56.112.116]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
Dec 1 17:18:27 postfix/smtpd[16619]: 1FAD011400DF: milter-reject: DATA from mail-db3on0104.outbound.protection.outlook.com[157.55.234.104]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
Dec 1 17:29:46 postfix/smtpd[9276]: 254AA114014A: milter-reject: DATA from mail-db3on0110.outbound.protection.outlook.com[157.55.234.110]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
Dec 1 17:33:29 postfix/smtpd[5122]: 81EC11140143: milter-reject: DATA from mail-db3on0102.outbound.protection.outlook.com[157.55.234.102]: 451 4.7.1 Service unavailable - try again later; from=<[email protected]> to=<[email protected]> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>

And now we are trying to explain to the client why the email from <[email protected]> took 6 hrs to arrive yesterday and when they can expect the email they expected 2 hrs ago!
 
The server settings are are follows -

/usr/local/psa/bin/grey_listing --info-server
Grey listing configuration.

Grey listing checking enabled
Grey interval 5 minutes
Expire interval 51840 minutes
Penalty interval 2 minutes
Penalty disabled
Personal grey listing
configuration allowed

Server-wide black list:
*@aexp.com
[email protected]
[email protected]
[email protected]

Server-wide white list:
*@*.gmlnt.com
<long list of domains removed>

White domains patterns list:
*.ebay.com
*.microsoft.com
*.outbound.protection.outlook.com
*.smtp-out.eu-west-1.amazonses.com
account.microsoft.com
addlocalhost6
addlocalhost6.localdomain6
localhost
localhost.localdomain
localhost4
localhost4.localdomain4
gmlnt.com
<some client domains removed>

Any help gratefully received! :)
Thanks
Greg
 
Hi gregconway,

And now we are trying to explain to the client why the email from <[email protected]> took 6 hrs to arrive yesterday and when they can expect the email they expected 2 hrs ago!

This is one of the disadvantages of greylisting, with domains with a lot of IPs, during the "setup time".


I think you should be informed about some facts. You seem to think, that adding a whitelist - domain as for example "*.outbound.protection.outlook.com", will automatically whitelist all depending IPs - which is NOT the case. Your system has to learn each of the IPs, which is in the "*.outbound.protection.outlook.com" - case:

Code:
23.103.132.0/22
23.103.144.0/22
23.103.191.0/24
23.103.198.0/23
23.103.200.0/21
23.103.136.0/21
40.107.0.0/16 
64.4.22.64/26
65.55.83.128/27
65.55.88.0/24
65.55.169.0/24
94.245.120.64/26
104.47.0.0/17
134.170.132.0/24
134.170.140.0/24
134.170.171.0/24
157.55.133.160/27
157.55.158.0/23
157.55.206.0/23
157.55.234.0/24
157.56.73.0/24
157.56.87.192/26
157.56.108.0/24
157.56.110.0/24
157.56.111.0/24
157.56.112.0/24
157.56.206.0/24
157.56.208.0/22
207.46.51.64/26
207.46.100.0/24
207.46.101.128/26
207.46.163.0/24
213.199.154.0/24
213.199.180.128/26
216.32.180.0/24
216.32.181.0/24
and
Code:
2a01:111:f400:7c00::/54
2a01:111:f400:fc00::/54

Please note, this are not single IPs, but IP - ranges!



Now we are jumping over to the greylisting - function itself:

I am trying to explain the worst case scenario, because this will point directly to the disadvantages of greylisting.
Mail - server A with IP 111.111.111.111 ( mailA-1.domain.com ), 111.111.111.1112 ( mailA-2.domain.com ) and 111.111.111.113 ( mailA-3.domain.com ) delivers a mail to your server, where you setup greylisting for *.domain.com .
The first mail delivery from "111.111.111.111" will be temporarily rejected, because your mail - server doesn't know the IP "111.111.111.111". This is a absolute normal behaviour from greylisting!
The first retry will now be delivered over "111.111.111.112", but again rejected from your server, because it now knows "111.111.111.111", but not yet "111.111.111.112".
The second retry will now be delivered over "111.111.111.113" and again, your server didn't see this IP before and so it will be rejected again temporarily, because like with the previous deliveries, the first IP - delivery will always be rejected.

But due to the case, that *.domain.com only has 3 mail - IPs, the waiting is now over for the third retry, becaue what ever IP is used now, your server saw the IP before and due to the case, that the domain is whitelisted, the mail - delivery will now succeed.


Again, we are now jumping back to "*.outbound.protection.outlook.com" and its IPs. Due to the case that your server didn't see all IPs yet, you will experience issues like described as often that a mail - delivery is sent over a "*.outbound.protection.outlook.com" - IP for a very first time and you will experience delays, as long as not all depending IPs from "*.outbound.protection.outlook.com" are known to your server.

Let's have a look what "Google" has to say about such issues ( Source: https://support.google.com/mail/answer/180063?hl=en ):

Message delays due to greylisting
With greylisting, the recipient domain temporarily rejects messages from IPs that it may not recognize, with the expectation that if the message is legitimate the sender will try again. However, Gmail may not always retry from the same IP. As a result, messages sent from Gmail to a domain that employs greylisting may be delayed.

If you are a domain owner and you're finding that messages from Gmail are delayed, we recommend not using greylisting, and instead use SPF or DKIM authentication to ensure fewer message delays from Gmail. If using SPF or DKIM isn't feasible, then we recommend whitelisting gmail.com and googlemail.com specifically.



Apart from all, your settings for
Code:
account.microsoft.com
addlocalhost6
addlocalhost6.localdomain6
localhost
localhost.localdomain
localhost4
localhost4.localdomain4
gmlnt.com
and "*@*.gmlnt.com" are incorrect / nonsense and will never match. The correct usage is:

*@subdomain.domain.com ( whitelists all mail-names from "@subdomain.domain.com" )
*.subdomain.domain.com ( whitelists all mail-names from all subdomains of "*.subdomain.domain.com" )
*.domain.com ( whitelists all mail-names from all subdomains of "*.domain.com" ).



Greylisting is a constant process and the configuration is never "finished". You have to control your log - files and you will add/remove/modify based on the actual logs.

You might consider to use as well "postfix - postgrey" for example. That gives you the possibilty to use "/etc/postfix/postgrey_whitelist_clients", "/etc/postfix/postgrey_whitelist_clients.local" and "/etc/postfix/postgrey_whitelist_recipients", where you can define your whitelist a bit more easier. Please see "http://linux.die.net/man/8/postgrey" for the documentation and use for example:

For Office 365 - servers:
Code:
/.*outbound.protection.outlook.com$/
 
Hi UFHH01,

Thanks for the detailed explanation. My first question in this post was "Could somebody please confirm whether greylisting looks at just hostnames or IP addresses as well?" and you have just confirmed that it does indeed use IP addresses, so that does explain (most of) the issues I'm having, although it still doesn't explain why emails from Ebay aren't getting through. Unless they have so many servers that the emails eventually expire before re-trying the first email server!

The "postfix - postgrey" is new to me, however, and that seems to be exactly what I am looking for. I've had a brief look through the reference page you've sent me and really what I need to know now is whether setting this up will interfere with the Plesk greylisting, as it seems they would be separate systems. Certainly the Plesk greylisting does not appear to have created any of the "postfix - postgrey" directories. So am I best to completely switch off the plesk greylisting before I proceed?

With regards my whitelisting setup - information on the Plesk greylisting is very sketchy. There is just the on/off switch within the GUI and the rest has to be configured using CLI, so I have worked from the CLI manual here - http://download1.parallels.com/Plesk/Doc/en-US/online/plesk-unix-cli/index.htm?fileName=63188.htm and used the examples provided. If I've missed a Plesk manual on this somewhere I'd be very grateful if somebody could point me toward it. If not then the Plesk documentation would probably benefit from some additional information here!

Ultimately I'm left with one burning question... why does the Plesk implementation of greylisting not follow the example of "postgrey"? The postgrey manual says "Note that you shouldn't use the --lookup-by-host option unless you know what you are doing: there are a lot of mail servers that use a pool of addresses to send emails, so that they can change IP every time they try again" and it looks like the Plesk implementation is doing exactly that, and hence is doomed to failure (or very delayed emails), whereas by not using the IP address it seems the whole system would be a lot faster and more reliable!

I'm sure there's a good reason why it's built this way but maybe this is something Odin could look at in a future patch/release?

Anyway thanks again for the clarification and pointers. If you or somebody at Odin could confirm whether I need to switch off Plesk greylisting or leave it on before I proceed with postgrey then I will get onto that ASAP!

Thanks,

Greg.
 
Any thoughts anybody? will postgrey and the plesk greylisting play together or should I switch the plesk greylisting off first?! Thanks.
 
@gregconway

No thoughts, I just simplify the facts as already stated (in a lenghty fashion) by UFHH01:

- SPF, Domainkeys and similar are preferred over grey listing (for many reasons),
- grey listing can cause some delays, only in a small number of occasions: in "the first part of the learning process",
- grey listing is not strictly necessary, when using SPF, Domainkeys etc.
- postgrey is not necessary at all,
- the standard Plesk setup for grey listing, augmented with some (proper) whitelisted domains, will suffice

and that is all.

In short, it can do no harm in having grey listing switched on OR off.

And if you are worried about the penalty of performance, be aware that most of the initial issue with grey listing will quickly resolve "by themselves".

Regards.....
 
Back
Top