Inbound emails are not working with antispam

07/26/2023 98 People found this article helpful 489,611 Views

Description

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

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

Troubleshooting

Do a packet capture with Source IP address as connecting IP address (In this case 198.24.165.101) and destination port as 25 (SMTP) and make sure that there are packets being received in the UTM without any drop on port 25 from this IP address.
Do a packet capture with destination IP address 204.212.170.13 (COLO IP address) and destination port 25. Once the packet capture is setup, do a telnet from source IP address on MX IP address on port 25 and see what is happening with the traffic to Colo. Capture should show packets getting redirected to COLO server IP address 204.212.170.13. If there is an issue with the specific redirect Policy (Policy 11), packets may drop.

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.

Troubleshooting:

Configure a packet capture with destination port 10025 and see if there are packets coming from SonicWall COLO IP addresses (204.212.170.13, 204.212.170.10 or any IP address in 204.212.170. range).There are chances that Syn flood protection may drop these packets. Disable SynFlood Protection for Inbound SMTP on port 25 as well as 10025 in that case. If there are no packets that means Colo server is not able to communicate with 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).

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

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.

Not Finding Your Answers?

ASK THE COMMUNITY

Was This Article Helpful?

YES NO

Inbound emails are not working with antispam

Description

Resolution

Related Articles

Categories

Not Finding Your Answers?

Was This Article Helpful?

Article Helpful Form

Article Not Helpful Form

Follow Us

Subscribe to newsletter

Stay In Touch