Inbound emails are not working with antispam

Inbound emails are not working with antispam

Question:-

How to troubleshoot inbound Email flow issues with Anti-spam?

Answer :-

1) Sender Mail server / Sender MTA IP address: 198.24.165.101
2) Default active WAN IP and MX IP address: 182.71.241.146
3) UTM Lan & Wan interface IP address: 192.168.170.35 & 182.71.241.146
4) Mail server and Junk store IP address: 192.168.170.10    
                                                 

Fig 1.1

There are two important NAT rules and three Back up NAT rules for Anti-spam. Both of the important NAT policies which normally will be used for email processing in Anti-spam has been explained below with packet capture. Troubleshooting steps are also explained as part of each policy. Remaining 3 policies are covered at the end of the document with brief description. Also there are two Firewall access rules which opens port 10025 on Default active WAN IP and port 25 on MX IP address which is not explained in this document.

NAT Policy 1 (Policy to accept all inbound SMTP connections and redirect to COLO)

The above Policy redirects all Incoming SMTP connections from Sending Mail servers to Email Security Service site (COLO). The COLO receives it at Inbound SMTP port (default: 25) and sees the source as coming from the UTM. Below Packet capture shows the redirection of inbound connections.
 The above packet capture also shows the Three way TCP handshake between the
Sender --> UTM device --> COLO server
 

If there are no drops till now, that means, Connection A and B in Fig 1.1 are successfully completed and should be a getting a response as below which is nothing but the SMTP banner from COLO server. (Below response is for a telnet connection request from Command prompt in sender server).

Nat Policy 2 (Policy to accept all incoming connections from COLO on port 10025)

Above policy accept Incoming connections from COLO for processed emails on Anti-Spam service port 10025 and directs to the Junk Store.


The above packet capture shows communication from COLO server back to UTM and then to the Junk store server when EHLO packet is being sent by the sender server (In this case 198.24.165.101).

COLO --> UTM (10025) --> Junk Store (10025) --> Mail server (25)

NOTE: If Colo server does not get a response from Mail server, further communication will be dropped and there won’t be a response for EHLO command. Also the communication from Junk store server to Mail server won’t be shown in the packet capture as that connection is local and behind the UTM.If you do not see these packets that means Colo is not able to communicate with your UTM device on port 10025 due to ISP or any other device sitting in front of UTM blocking port 10025. There are chances that ISP’s may block SMTP communication on non-standard ports like 10025.
 

If packet capture shows packets from COLO on port 10025 that means connection C in Fig 1.1 is passed successfully and there should be a response as below (If connection D or connection E fails we may not get below response as Junk store is just a bridge and not an MTA, then go to next troubleshooting step).

NOTE: There might be different servers for different roles of exchange. In most cases, we should be looking for log files in a server which is handling Front end role or under Front end folder under Transport roles. 

If there are entries for mail transaction like ‘mail from’ in MlfAsgSMTP log and receive connector log that means connection D and E is passed and most probably it is the exchange server responsible for mail flow failure. Receive connector log and MlfasgSMTP log will help to either fix the issue or at least reach a conclusion whether it is the customer’s exchange server or UTM causing the mails to be dropped.
 

Troubleshooting: A quick way to test port 10025 connectivity and get an error code in Exchange receive connector log (if Exchange is dropping connections) is to do the below telnet test. Disable or stop junk store services and make sure Anti-spam status page shows Junk store is unavailable and then Tenet to the Default active WAN IP on port 10025 which will be NATed to Exchange server’s local IP address on port 25. Response should show SMTP banner directly from Exchange server. Once the Telnet session is enabled, send a test mail via the session. If port 10025 is not reachable due to ISP or another device, SMTP banner will not come up (A packet capture could also be setup to see if firewall is dropping these packets). If SMTP banner appears and still mail flow is down, check receive connector logs in Exchange server.   NOTE: Above test is bypassing COLO server as well as junk store which eliminates possibilities of junk store and COLO dropping connections and will pin point whether it is UTM or Exchange or ISP causing the issue.

 
Coming back to the remaining three NAT rules.

Nat Policy 3 (Policy to process emails when COLO server is down)

Above rule is used when COLO server is unavailable (Means UTM is not able to connect to COLO server / 204.212.170.13 on port 25). It basically routes the email from sending MTAs direct to the Junk Store.

Nat Policy 4 (Policy to process emails if Junk store is down or unavailable)

Above rule comes into picture when there is no Junk Store or Junk store exists but unavailable, the Processed emails from Security service site is routed directly to Destination Mail Server. When the processed emails reach UTM on port 10025, port will be translated to 25 and then will be forwarded to Exchange server bypassing junk store server.

Above packet capture shows how emails are processed when junk store is not available. Please notice packets 74 and 75 where COLO server attempting to connect to junk store on port 10025 and utilizing the NAT policy 4 and connecting to mail server on port 25. (You would not be seeing a drop or rejection from junk store server because, SonicWall already knows that Junk store is not available and it needs to use NAT policy number 4 to process emails further).

Nat Policy 5 (Policy to process Emails when COLO as well as Junk store is unavailable)

Above rule process emails while both Anti-spam Service and Junk Store is unavailable. It just sends all Incoming emails from MTAs directly to Destination Mail Server.
 
Below image is a sample Telnet session which shows basic SMTP commands used in an Email transaction.