We've enabled greylisting but have noticed that emails from Office365 and others are getting delayed for hours or days. The problem occurs when the retry comes from different server IP, after different server IP, after different server IP. Whitelisting the sender domain works but only for known clients. If you receive email from a new customer, it's not nice to ignore their request to purchase something for hours or days. 2 customers of ours had to have greylisting disabled as they were losing business.
are you sure sqlgrey is not suitable to whitelist i.e. outbound.protection.outlook.com?
as far as I can see you have the options of whitelisting with /etc/sqlgrey/clients_fqdn_whitelist.local (see /etc/sqlgrey/clients_fqdn_whitelist for examples) where you can add outbound.protection.outlook.com and *.outbound.protection.outlook.com as far as I can see.
If you like you could add IP ranges too: /etc/sqlgrey/clients_ip_whitelist.local
and /etc/sqlgrey/discrimination.regexp for more discrimination
The number of people using Office 365 is growing exponentially! Other sources of grief for SQLGrey are any Cloud email security solution like Symantec Cloud, McAfee/Intel's MXLogic (soon to retire), Barracuda, etc. where users route outbound email through their Cloud solution. MXLogic alone has 208.65.144.0/21 and 208.81.64.0/22 for mail servers.
Thanks for the heads-up on these options of whitelisting with /etc/sqlgrey/clients_fqdn_whitelist.local and via IP ranges in
/etc/sqlgrey/clients_ip_whitelist.local.
dbrunt, yeah agreed, office365 has crippled sqlgrey. Here is a list of "Exchange Online Protection IP addresses" They hop around like rabbits when initiating connections.
I'm still waiting for someone to confirm if it isn't easier doing it this way:
/etc/sqlgrey/clients_fqdn_whitelist for examples) where you can add outbound.protection.outlook.com and *.outbound.protection.outlook.com as far as I can see.
rather than via that huge list of IPs which can and will will grow eventually. I don't get enough traffic to be able to reliably test this.
ovizii wrote:I'm still waiting for someone to confirm if it isn't easier doing it this way:
/etc/sqlgrey/clients_fqdn_whitelist for examples) where you can add outbound.protection.outlook.com and *.outbound.protection.outlook.com as far as I can see.
rather than via that huge list of IPs which can and will will grow eventually. I don't get enough traffic to be able to reliably test this.
I've added outbound.protection.outlook.com and *.outbound.protection.outlook.com and will see what happens...
ovizii wrote:I'm still waiting for someone to confirm if it isn't easier doing it this way:
/etc/sqlgrey/clients_fqdn_whitelist for examples) where you can add outbound.protection.outlook.com and *.outbound.protection.outlook.com as far as I can see.
rather than via that huge list of IPs which can and will will grow eventually. I don't get enough traffic to be able to reliably test this.
I've added outbound.protection.outlook.com and *.outbound.protection.outlook.com and will see what happens...
Confirmed.
After adding those two entries, we received an email which had previously been auto-whitelisted by SQLGrey:
The new email header now has this:
This would indicate to me that the outbound.protection.outlook.com entry kicked in...
Last edited by dbrunt on 28 Jul 2016 21:46, edited 1 time in total.
However a new (possible) issue I'm seeing now is most emails from outbound.protection.outlook.com without the X-Greylist: header meaning SQLGrey did not process the email?
+# StartSSL: no retry
+*.startcom.org
+*.startssl.com
+
[b]+# Outlook.com users, retries do not come from the same server.
+*.outbound.protection.outlook.com [/b]+
+
# Do not add anything here (this file can be overwritten by SQLgrey updates and
# update_sqlgrey_config), create a "clients_fqdn_whitelist.local" file
# and add your own entries in there
updating /etc/sqlgrey/smtp_server.regexp:
--- /etc/sqlgrey/smtp_server.regexp 2015-02-26 18:45:56.422999767 -0800
+++ smtp_server.regexp 2005-03-01 16:29:45.000000000 -0800
@@ -1 +1 @@
-^(.+[._-])*(apache|bounce|bulk|delay|d?ns|external|extranet|filter|firewall|forward|gateway|gw|m?liste?s?|(bulk|dead|mass|send|[eqw])?mail(er)?|e?mail(agent|host|hub|scan(ner)?)|messagerie|mta|v?mx|out(bound)?|pop|postfix|w?proxy|rela(is|y)|serveu?r|smarthost|v?smtp|web|www)(gate|mail|mx|pool|out|server)?[0-9]*[._-]
\ No newline at end of file
+^(.+[._-])*(apache|bounce|bulk|delay|d?ns|external|extranet|filter|firewall|forward|gateway|gw|m?liste?s?|(bulk|dead|mass|send|[eqw])?mail(er)?|e?mail(agent|host|hub|scan(ner)?)|messagerie|mta|v?mx|out(bound)?|pop|postfix|w?proxy|rela(is|y)|serveu?r|smarthost|v?smtp|web|www)(gate|mail|mx|pool|out|server)?[0-9]*[._-]
[root@efa sqlgrey]#
ovizii wrote:hehe, seems we were on the right track
Yes it would seem so.
So instead of adding all of Symantec's & MXLogic's IPs, I've added *.messageLabs.com and *.MXLogic.net to /etc/sqlgrey/clients_fqdn_whitelist.local