SmarterMail integration with SpamExpert not working
Problem reported by Izzati Zaidi - 5/14/2020 at 6:40 AM
Hi, I would like to ask what is the setting that I need to do if I want to apply SpamExpert in SmarterMail other than configure the outbound filtering in Setting > Gateways / Failover. 

This is because we having an issue unable to send an email with error message "Error 451: unable to verify sender". SpamExpert team asks us to refer to the SmarterMail to confirm the integration setup / MTA configuration.

They recommend that this should be investigated and resolved on the aforementioned destination mailserver, so that they can always verify using callouts. This is the URL that related to this issue but I'm not sure where I need to setup in SmarterMail interface: https://documentation.solarwindsmsp.com/spamexperts/documentation/Content/Integration/ensure-deliv-server.htm 

Thank you.

2 Replies

Reply to Thread
Netmate Replied
We would also want to do hostname-based whitelisting instead of IP address based.

As stated by SpamExperts... "To only accept messages from the Spamexperts filtering servers, one need to allow emails based on hostname "delivery.antispamcloud.com". This hostname contains all active delivery IP addresses. Alternatively one can allow traffic from any IP address with the PTR record *.antispamcloud.com." 

Anybody knows how to achieve this in SmarterMail?
Douglas Foster Replied
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.

Reply to Thread