You want to be VERY careful about whitelisting any server's IP address: especially a server which is running PHP!
I share this thought because about four years ago I was contracted to resolve a spamming issue on a server in Stockholm Sweden. The ISP was running both SmarterMail and IIS - with about 160 websites running, and many of them were running PHP. The owner of the small ISP was extremely careful with his security and passwords, and there were multiple levels of encryption and VPNs to connect - overall excellent security.
There were no SMTP bypasses. There were no white listed IP addresses in SmarterMail.
We used every available tool to monitor the networks - working for almost 3 days, to vet the source of the more than 500,000 spam messages per hour which were being generated - and none of them were SMTP authenticated, with everything going through SmarterMail. The customer was running an early version of SmarterMail 7.X, so the log reporting was not nearly as good as it is in SmarterMail 14.X. That meant we were limited to Microsoft logs, IIS logs (which were mostly useless in this case), and monitoring - using every available tool and resource then available.
Long story short: The ISP owner's daughter had a hair salon. It had been built in PHP, and, with the exception of new hours, had not really been updated in several years.
It turns out that the owner's daughter's website was the weak link, but, because he had some large business sites hosted on the server, he was unwilling to allow me to just turn off IIS to see if that stopped the problems.
In sheer frustration, I finally disabled IIS and the spam stopped - cold.
I then disabled all of the websites, individually, and restarted IIS, and there was still no spam.
So, I enabled the websites, one at a time, and, withing seconds of re-enabling his daughter's hair salon website, which was written in PHP, the spam started flowing again.
Now I had a clue to work with and we were able to find out where someone had gone into the actual SmarterMail configuration files and white listed all of the websites using a text editor. These edits were not showing up in the SmarterMail interface, so there was no reason to think anything was white listed in SmarterMail.
We found the edit, removed the white listed sites, and had his web development team redo the e-mail sending capabilities of each of the sites to enforce full SMTP authentication.
Problem resolved. Spam ended, but not before close to 10 million spam messages had attempted to flow through the ISPs SmarterMail system.
While whitelisting may be tempting -- it's a "quick and dirty fix," it's never a good idea. The better solution is to re-code the website(s) in question, and run proper SMTP authentication on all contact forms, newsletter sign up sheets.
There's another reason to use proper SMTP authentication, too: Many large ISPs, taking the lead of YAHOO!, have begun to look for an indication in the e-mail header that indicates that the message was properly SMTP authenticated.
SmarterMail 14.X provides this vehicle in the form of an "X-SmarterMail-Authenticated-As" message header record.
In the example below, with some of the data obfuscated to protect the identity of the server from which it was sent, you can see how that "X-SmarterMail-Authenticated-As" is inserted in the header.
Received: from mail.REDACTED.fr (mail.REDACTED.fr [XXX.XXX.XXX.XXX]) by securemail.chicagonettech.com with SMTP
Wed, 23 Dec 2015 09:15:55 -0600
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
Received: by mail.REDACTED.fr via HTTP;
Wed, 23 Dec 2015 16:15:40 +0100
From: "Bruce Barnes - SmarterMail Consultant" <bbarnes@oREDACTED.com>
Subject: MailTest REDACTED.COM 201512230914 CST - GMT -0600 | 201512231614 GMT +0100
Date: Wed, 23 Dec 2015 16:15:40 +0100
Content-Type: multipart/related; boundary=ae61246c6a8a48f3aad6b30afc8a7bc3
X-SmarterMail-Spam: SPF_Pass, DK_None, DKIM_Pass
In the header record shown above, the use of SMTP authentication has not only allowed SmarterMail to insert the X-SmarterMail-Authenticated-As: bbarnes@REDACTEDe.com, but is further enhanced by the fact that SmarterMail 14.4 now fully supports TLS 1.2, the highest possible level of data encryption.
When coupled with SPF, rDNS, and DKIM, this also enables DMARC, which, along with the valid use of SMTP AUTHENTICATION, for every message sent via SmarterMail, or any other e-mail server, will help to ensure that your e-mail server does not, because of the use of whitelisting, become an open relay or source of spam.
For more information on how to ensure your e-mail delivery, please see my document at: Why Am I Having Problems Getting My E-Mail Delivered?
Phone: (224) 444-0169
E-Mail and DNS Security Specialist
Network Security Specialist
Customer Service Portal: https://portal.chicagonettech.com
Security Blog: http://networkbastion.blogspot.com/
Web and E-Mail Hosting, E-Mail Security and Consulting