|Relaying of an external client|
Enable Inbound authentication in XWall in Options->General->Authentication
Note: If you selected pass-through NTLM logon and XWall runs as a service, then make sure you start the service with an domain account or else the authentication will not work.
Enable relaying for authenticated users in XWall in Options->General->Relay
Enable SMTP authentication in the e-mail application of your external client
Usually Outlook Express or whatever your clients uses.
Send a test message from the external e-mail client to someone in the Internet
Do not send a message to an e-mail address on your Exchange, because this is not relaying and XWall will accept it in any case.
In the case the external e-mail client gives you some error, then check the logfile of XWall ( mb.log ) if the external e-mail application really authenticates
Here is a sample of an authentication:
The bold lines are the authentication commands and if they are not there, then the external e-mail client does not start to authenticate.
The reason could be:
SMTP authentication is not enabled the external e-mail client
SPA SMTP authentication is enabled in the external e-mail client
This will not work, because XWall needs to have the user and password in clear text to perform the NTLM pass-through authentication.
Check that no SMTP proxy is blocking at the firewall
CICSO PIX and the Checkpoint firewall by default install a SMTP proxy that prevent all ESMTP verbs and so authentication can't be done.
The only solution is to disable the SMTP proxy
|Create a rule in Outlook based on Internet header lines|
XWall adds some Internet header lines to the messages and this lines can be used to trigger rules in Outlook.
Note: If you want that XWall triggers a rule for every spam message, then check for the presence of the X-XWall-Spam: header line.
|Create a rule in Exchange 2007/2010 based on Internet header lines|
XWall adds the X-XWall-Spam Internet header lines to spam messages and this lines can be used to trigger rules in Exchange 2007/2010 Hub that sets the SCL, and in turn, moves the message to the Junk-E-Mail Folder.
In Exchange 2010 the Powershell command for the rule is:
New-TransportRule -Name 'Move To Junk'
In Exchange 2007 the Powershell command for the rule is:
$Condition = Get-TransportRulePredicate HeaderContains
Note: In most cases the Hub needs to be restarted or the rule will not trigger.
|Running on the same machine as Exchange but with a different IP|
The following example assumes your Exchange servers are running on EXCH1.domain.com ( 10.0.0.1 ) and EXCH2.domain.com ( 10.0.0.2 ) and you want to run XWall on EXCH1.domain.com on a new IP address ( 10.0.0.3 )
Stop XWall and Exchange Virtual SMTP Server
Add 10.0.0.3 as a second IP address to EXCH1.domain.com
Start MBAdmin, select View->Advanced Configuration->IP Address->Bind to address and type in 10.0.0.3
Select Options->Exchange->Name or IP of Exchange and type in 10.0.0.1
Select Options->Exchange->Exchange listens on port and type in 25
Start System Manager (Exchange Admin) and select Servers->Your Server->Protocol->SMTP->Default SMTP Virtual Server->Properties .
Then select the tab labeled General and then Advanced and type in 10.0.0.1 as the IP address and 25 as the port.
Disable SMTP Service Socket Pooling or else the Virtual SMTP Server will still listen on both IP addresses.
To disable it see
for IIS 6.0 How to Disable Socket Pooling
Start Exchange Virtual SMTP Server and verify that Exchange listens only at 10.0.0.1 and not on 10.0.0.3
Note: This is the critical part of the whole configuration!
Open a DOS box and type
telnet 10.0.0.1 25
and you should get a greeting from Exchange.
Open a DOS box and type
telnet 10.0.0.3 25
and you should get a connection error.
If you get a greeting from Exchange then Exchange is listening on 10.0.0.3 and there is something wrong with the settings in Exchange Virtual SMTP Server.
Start XWall and verify that XWall starts without any errors
|Two or more Exchange in the same organization|
The following example assumes you have one Exchange in New York and a second in Los Angeles and XWall should be a central point for incoming and outgoing messages.
Install XWall on a separate machine or a separate IP
Define one of the two Exchange as the bridgehead server and this Exchange is the only Exchange that talks to XWall
So the message flow would be, assuming New York is the bridgehead:
Internet -> XWall -> New York -> Los Angeles
Note: All internal traffic between the Exchange in New York and Los Angeles needs to go directly without going over XWall or else you may get blank mesages
( see KBXW028 )