Let's begin by clarifying the problem statement:
You are subscribing to a cloud-based platform which uses the SpamExperts product as its anti-spam tool. This site will sit in front of your perimeter firewall and your mailserver. Consequently, the two systems will operate independently of each other.
The cloud site (presumably
antispamcloud.com) is supposed to be your first line of defense, so you want to block any email traffic that attempts to bypass it by connecting directly to your mail server.
Identifying incoming traffic from them
I am appalled that they cannot configure you so that all of your incoming traffic will come from a small number of known IP addresses. Doing a DNS-based filter is outside the scope of most firewalls (where the filter should be implemented) and they should know that. Additionally, the filter rule is only safe if you actually do forward-confirmation of the host name back to the source IP (which is another difficult-to-obtain feature). The problem is doubled if you decide that LDAP verification is the way that you want to do recipient verification. This is a show-stopper in my book, but sometimes the show is already started by a higher-level manager and your job is to make do as best you can.
You might be able to use a SMTP Filter on host name (although the documentation implies that this is intended for outbreak control of outgoing messages) or using a RegEx on the Received header. You could also integrate SmarterMail with Declude (from MailsBestFriend) and do it using a Declude filter.
Recipient verification:
There are three ways to perform sender authentication:
- Using LDAP
- Callout using the VRFY (verify) command. Many systems do not respond to VRFY to prevent directory harvesting.
- Callout using a HELO for a fake message, which is then abandoned.
- None - let the message through and let SmarterMail reject what it cannot handle.
If seems obvious that you have not configured your security to allow the verification to occur, but I cannot tell you where the problem starts. You need to know which technique your vendor is trying to use, then determine how to configure SmarterMail to accept the action. SmarterMail support can help you with this process once you have details.
SmarterMail 16 has a variety of bugs related to Sender Authentication. In general, LDAP will miss a few things, so it is not usable. Callout will accept some traffic that is not deliverable, but I do believe it will reject anything which is valid. All of the bugs have been addressed in the V17 development cycle, so those problems can be avoided if you are willing to run a Beta version.
SpamExperts, the product
When I was shopping, I found that SpamExperts is at least 80% of the cost of ProofPoint or Mimecast, but not 80% of the functionality. You have no way to configure multi-attribute allow or block rules. Suppose that
Example.Com switches to
Outlook.Com but does not update their SPF record. Your choices are:
- Whitelist anything that pretends to be from
Example.com- Whitelist anything that pretends to be from
Outlook.com- Disable SPF for everything
- Get by without the ability to receive mail from
Example.com until you can convince them to fix their SPF record.
And SpamExperts does not have granular whitelisting, so if you whitelist for SPF, you also turn off most other content filtering. I assume they block obvious malware attachments even if a message is whitelisted.
To my mind, the only acceptable product is one that allows me to say: "Enforce SPF, but as an exception, ignore SPF failure for messages from
Example.Com when sent by Outlook.com" (It should also do forward-confirmation of
Outlook.Com host names for completeness.) And SPF Failure is the only thing that is overlooked, unless you choose to implement a more permissive rule. These two requirements, multi-attribute exceptions and granular exceptions, will eliminate a lot of commercial products.