Mail is being queued up on the upstream MTA

book

Article ID: 160660

calendar_today

Updated On:

Products

Data Loss Prevention Network Prevent for Email Data Loss Prevention

Issue/Introduction

Mail is being queued up on the upstream MTA.  Some messages are being processed but pending email messages continue to build. 

 

Cause

While analyzing the SmtpPrevent_operational0.log found the below entries (Relevant components marked in bold for purposes of this article):

 

12/Jun/12:08:32:31:506-0500 [SEVERE] (SMTP_CONNECTION.5203) Forward connection error (tid=27 cid=875 mta=[mta] reason=null)

12/Jun/12:08:32:31:506-0500 [SEVERE] (SMTP_CONNECTION.5210) All forward hosts unavailable (tid=27 cid=<> reason=No available forward hosts)

12/Jun/12:08:32:31:506-0500 [INFO] (SMTP_CONNECTION.1205) Service connection closed (tid=27 cid=875 local=x.x.x.x:25 remote=y.y.y.y:8679 messages=0 time=20s)

 

You may also see successful messages similar to the below (Relevant components marked in bold for purposes of this article)

[INFO] (SMTP_MESSAGE.1300) Message complete (tid=27 cid=Upstream-6d756ad9-2602-4adc-a3cb-151780b9dc5a message_id=<[email protected]> dlp_id=17eafa790eb size=123,456 sender=<[email protected]> recipient_count=3 disposition=PASS code=250 estatus=<> text=<OK ([email protected]:250 2.0.0 AB482174273408F16e497bb8a mail accepted for delivery,recipient2.domain.tld:250 2.0.0...)> rtime=10.06s dtime=0.50s mtime=100.09s)

Resolution

The "forward hosts unavailable" errors indicate that SMTP prevent is not able to connect to the next downstream MTA - which may have stopped accepting connections from DLP.

It's possible the settings on that MTA need to be checked - such as limits to connections, or timeouts for existing connections.

 

However, with the presence of the "successful" messages as well, it may also be an issue with slow processing on the downstream MTA and/or network latency between DLP and the MTA.  The key components are the rtime, dtime and mtime seen in the logs.



Rtime = time in seconds for Network Prevent for Email to fully receive the message from the sending MTA.  (from the time the connection is open until we receive the "." denoting the end of the email)

dtime = the time in seconds for Network Prevent for Email to perform detection on the message. (handled by File reader and Content extraction host. See their respective logs for detection details)

mtime = the total time in seconds for Network Prevent for Email to process the message. (Complete time DLP handled the message until the "." is recieved by the downstream MTA and the connection is closed)


In the above example, we can see rtime=10.06s dtime=0.50s mtime=100.09s.  To put into human terms, it took ~10 seconds for DLP to get the message, DLP handled it for half a second, and then it took ~90 seconds to send it to the downstream mta. 

the send time is calculated as

Send time = (mtime) - (dtime) - (rtime) 

In this instance you should analyze the connection between DLP and the downstream MTA as well as the downstream's logs to see why it was so slow being recieved.