Note that the nssmtp.pl script bundled with the NetScaler will go as far as attempting to open a connection to confirm that the service is up. The script and the actual code can be found in the following directory of the NetScaler:

/netscaler/monitors

#!/usr/bin/perl -w

################################################################

##

## Copyright 1998-2016 Citrix Systems, Inc. All rights reserved.

## This software and documentation contain valuable trade

## secrets and proprietary property belonging to Citrix Systems, Inc.

## None of this software and documentation may be copied,

## duplicated or disclosed without the express

## written permission of Citrix Systems, Inc.

##

################################################################

## This is a netscaler supplied script. Please dont modify this as it will be overwritten during

## reboot. If you want to modify, please make a copy of this script and modify.

Complete the creation of the load balancing virtual server and you should see State and Effective State listed as being up:

Step #5 – Lockdown Open Relay for Exchange Receive Connector

One of the common mistakes often overlooked when configuring SMTP load balancing via the NetScaler is inadvertently allowing open relay on the Exchange Server’s receive connector traffic coming from the NetScaler would appear to be an internal IP to the Exchange server. One of the ways to test whether the receive connector allows for open relay is to execute the following commands via telnet:

Note that the mail from email address has a domain that is not hosted on the Exchange server and the rcpt to address is meant to be an email address that is also not hosted on the Exchange server. If the response to these commands is Recipient OK then your receive connect is allowing open relay. To correct this, ensure that the receiving connector has the Externally secured (for example, with IPsec) setting disabled:

Once the connect has been locked down, the following response is what the telnet commands would yield:

Another often overlooked issue that load balancing SMTP requests through a NetScaler creates is that the Exchange server’s receive connectors no longer see the true source IP address because all of the requests now originate form the NetScaler’s NSIP address which means a malicious or unauthenticated internal device could potentially relay mail off of the load balancing virtual server and be able to successfully have the Exchange server deliver the email. This could be addressed by either configuring the Direct Server Return (DSR) feature on the NetScaler or simply locking down which IP addresses can connect to the load balancing virtual server. I won’t cover the configuration of DSR and will point to one of my previous blog posts to demonstrate how to lock down the load balancing virtual server: