Inbound emails are not working with antispam

03/26/2020 88 People found this article helpful 104,503 Views

Download

Print

Share

• LinkedIn
• Twitter
• Facebook
• Email
• Copy URL The link has been copied to clipboard

Description

Inbound emails are not working with antispam

Resolution

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    
                                                 

Click To See Full Image.

                                                                           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)

Click To See Full Image.

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.
 

Click To See Full Image.

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).

Click To See Full Image.

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

Click To See Full Image.

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

Click To See Full Image.

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).

Click To See Full Image.

Troubleshooting:- Once the packets reach back to UTM from COLO on 10025 as you see in Fig 1.1, It gets NATed to the local IP address of the junk store server and connects to Junk store server on port 10025 to process the Email. Junk Store acts as a proxy Between COLO and Exchange server. At this point of time, all SMTP commands like Mail from, RCPT to etc. will be written to MlfasgSMTP log file in log level 2. If the Connection C is success and still mail flow is not working, we should be looking at MlfAsgSMTP logs which can be collected from Anti-spam --> Advanced page. Make sure the log level is 2 under Anti-spam --> Advanced page. A sample snippet from MlfasgSMTP log which shows connection from UTM to Junk Store server (Connection D in Fig 1.1). Connection D may fail if connection E fails as Junk store is a proxy and not an MTA. Click To See Full Image.   If exchange is dropping connections due to some reason, there would be error messages in MlfAsgSMTP log but may not show the exact reason for rejection. We could both suggest the customer to check with his Exchange expert or go ahead and collect Receive connector logs from Exchange server. For this purpose, logging should be enabled on the receive connector. Location for log files may vary in different Exchange server versions (Also the default log location might have changed). Exchange 2007 - C:\Program Files\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog\SmtpReceive Exchange 2010 - C:\Program Files\Microsoft\Exchange Server\ v14\TransportRoles\Logs\ProtocolLog\SmtpReceive   Exchange 2013 - C\:Program Files\Microsoft\Exchange server\V15\TransportRoles\Logs\FrontEnd\ProtocolLog\SmtpReceive

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.
 

 
Coming back to the remaining three NAT rules.

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

Click To See Full Image.

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)

Click To See Full Image.

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.

Click To See Full Image.

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)

Click To See Full Image.

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.

Related Articles

• SSL Control and DPI-SSL Compatibility
• FIPS Mode: Radius protected with IPSEC VPN
• Maximum DHCP Leases

Categories

• Firewalls > TZ Series
• Firewalls > SonicWall SuperMassive E10000 Series
• Firewalls > SonicWall SuperMassive 9000 Series
• Firewalls > SonicWall NSA Series