Hi.

Plesk: 12.0.18 Update #60, última actualización 18/Ago/2015 00:42
OS: Debian 7.7

We're facing high delays on mail sent from outlook.com hosted domains. The MTA at *.protection.outlook.com changes both server name and ip on every retry.
This causes a email sent at 12:46 be finally delivered at 01:24 next day.


syslog.1:Aug 27 12:46:42 hosting postfix/smtpd[10567]: 9C34C169A061: milter-reject: DATA from mail-db3on0064.outbound.protection.outlook.com[157.55.234.64]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 13:02:00 hosting postfix/smtpd[10960]: 347EE169A061: milter-reject: DATA from mail-db3on0087.outbound.protection.outlook.com[157.55.234.87]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 13:20:20 hosting postfix/smtpd[11474]: CCB40169A00D: milter-reject: DATA from mail-am1on0096.outbound.protection.outlook.com[157.56.112.96]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 14:20:51 hosting postfix/smtpd[13066]: 87617169A00D: milter-reject: DATA from mail-db3on0084.outbound.protection.outlook.com[157.55.234.84]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 15:21:17 hosting postfix/smtpd[14670]: 37F7B169A063: milter-reject: DATA from mail-am1on0058.outbound.protection.outlook.com[157.56.112.58]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 16:21:05 hosting postfix/smtpd[15881]: 68E83169A00D: milter-reject: DATA from mail-am1on0091.outbound.protection.outlook.com[157.56.112.91]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 17:20:52 hosting postfix/smtpd[17517]: 0255D169A00D: milter-reject: DATA from mail-am1on0063.outbound.protection.outlook.com[157.56.112.63]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 18:21:17 hosting postfix/smtpd[18870]: C4A14169A00D: milter-reject: DATA from mail-db3on0100.outbound.protection.outlook.com[157.55.234.100]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 19:22:18 hosting postfix/smtpd[20207]: 785B6169A00D: milter-reject: DATA from mail-db3on0076.outbound.protection.outlook.com[157.55.234.76]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 20:21:32 hosting postfix/smtpd[21342]: D9E70169A00D: milter-reject: DATA from mail-db3on0053.outbound.protection.outlook.com[157.55.234.53]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 21:22:22 hosting postfix/smtpd[22815]: 35A99169A00D: milter-reject: DATA from mail-am1on0060.outbound.protection.outlook.com[157.56.112.60]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 22:22:58 hosting postfix/smtpd[23716]: 3D3B7169A00D: milter-reject: DATA from mail-am1on0095.outbound.protection.outlook.com[157.56.112.95]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
syslog.1:Aug 27 23:23:56 hosting postfix/smtpd[24784]: E354E169A00D: milter-reject: DATA from mail-db3on0071.outbound.protection.outlook.com[157.55.234.71]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-db3-obe.outbound.protection.outlook.com>
syslog.1:Aug 28 00:24:33 hosting postfix/smtpd[25769]: BFBE1169A00D: milter-reject: DATA from mail-am1on0059.outbound.protection.outlook.com[157.56.112.59]: 451 4.7.1 Service unavailable - try again later; from=<sender_user@otheruserdomain.com.com> to=<recipient_user@destinythedomain.com> proto=ESMTP helo=<emea01-am1-obe.outbound.protection.outlook.com>
syslog.1:Aug 28 01:24:52 hosting postfix/qmgr[19800]: 02DA1169A00D: from=<sender_user@otheruserdomain.com.com>, size=51552, nrcpt=1 (queue active)

This obviously is not acceptable for my customers and there are several complaints about greylisting behaviour as some mails were quite urgent.
We're thinking about disabling grelisting server-wide.

Some questions at this point.

1.- White-list: White-lists are the first solution. Sure!
As sender domain is otheruserdomain.com and MTA name is *.outbound.protection.outlook.com, will whitelisting *.outbound.protection.outlook.com be enough to any domain hosted by outlook.com bypass greylist checks?

2.- If the answer is NO, is there any workaround different to whitelisting domains as they appears to be high delayed? This would be no acceptable for my customers.

3.- And final question. Do you think greylists are really effective against spam? Several SPAM servers are true and legitimate servers that were compromised/hacked, so even SPF and DKIM/DomainKeys are valid. And these servers usually try delivering

By now we have disabled greylist temporary.

Thank you

 

Hi VLopez,

Good idea, because greylisting does not only have delay - issues with Office365 - servers, but as well with Google - Mail. Here is, what Google recommends: https://support.google.com/mail/answer/180063?hl=en
Please be aware, that Microsoft and Google are not the only one, with a lot of IPs for their mail - servers, but if you would like a whole IP - list... here you go:

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

2a01:111:f400:7c00::/54
2a01:111:f400:fc00::/54

Source: https://technet.microsoft.com/en-us/library/dn163583(v=exchg.150).aspx

Actually, the Google recommendation is not bad at all, because greylisting requires constant mail - log - checks and modifications, while using correct MX/A/SPF/DKIM/DomainKeys/DMARC - settings, in addition with spamassassin and Fail2Ban - protections, will result in a far better security setting and spam - protection.

Well, using postfix - postgrey for example 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$/

A nice feature with Plesk is as well the command "/usr/local/psa/bin/grey_listing ...", please see:

/usr/local/psa/bin/grey_listing --help​

... for all possible commands with this Plesk utilty ( hint: /usr/local/psa/bin/grey_listing --update-server -domains-whitelist "add:*outbound.protection.outlook.com" )

 

Hello,

I added outbound.protection.outlook.com in /etc/postfix/whitelist_clients and also ranges of its in that file:

# Whitelist

104.47.0.0/17
40.107.0.0/16
/.*outbound.protection.outlook.com$/
/outlook/

Restart postfix and postgrey and it does not work:

Sep 8 12:51:23 dv4 postgrey[6790]: action=greylist, reason=new, client_name=mail-db5eur01on0139.outbound.protection.outlook.com, client_address=104.47.2.139, sender=isabel.lao@xxx.com, recipient=auxiliar@xxx.com

Sep 8 12:51:23 dv4 postfix/smtpd[26777]: NOQUEUE: reject: RCPT from mail-db5eur01on0139.outbound.protection.outlook.com[104.47.2.139]: 450 4.2.0 <auxiliar@xxx.com>: Recipient address rejected: Greylisted, see http://postgrey.schweikert.ch/help/xxx.com.html; from=<isabel.lao@xxx.com> to=<auxiliar@xxx.com> proto=ESMTP helo=<EUR01-DB5-obe.outbound.protection.outlook.com>

Sep 8 12:51:23 dv4 postfix/smtpd[26777]: disconnect from mail-db5eur01on0139.outbound.protection.outlook.com[104.47.2.139]

Any ideas?

 

Finally we decided to implement another approach dealing with spammers.
We stopped to use greylist.

The main reason was that there were legitimate servers getting greylisted, and spammers use lots of legitimate, but compromised, servers, so greylist tends to be innefective at all as the spam effectively rejected by greylisting is near to 0.

Now we're dealing with spam with finetunning SpamAssasin. We've found that using some public rulesets (KAM.cf - old and use at your own risk) and lowering serverwide scoring to 4.2 marks all as Spam and has a very low false positives and very high accuracy in tagging Spam as spam.

Also we implemented SPF + DKIM checking. It blocks some spam but it's not a full solution.

You can use Fail2Ban too. We use it.

Also we've implemented blocklists (again use them at your own risk).
There are some sites that keeps track of offending IPs or IP ranges.
(I.E.: http://www.blocklist.de/en/index.html)

We made a script (1) that get updates from that lists and blocks those IP at IPTables level (as Fail2Ban does).
We not only get a lot of spammers out but a lot of script kiddies, websites bruteforcing and som several attacks to our servers.


(1) An example https://n0where.net/iptables-blacklist-script/ (check actual urls and use at your own risk)