I don't think this is the reason, not abased on your initial screenshot. If it failed due to no STARTTLS, then you wouldn't get to the point of having the Sender address in the MAL. This address is pulled from the MAIL FROM: during the SMTP handshake, which would be past the point of STARTTLS.
So, the sender connected, provided a MAIL FROM and likely one or more RCPT TO (this would generate the MAL with Audit ID, Sender, and Connection Classification results). The typical point of failure for a MAL like this is during the DATA section, where the mta sends the contents of the message itself (the headers and the viewable body/attachments).
As was said before, a likely cause of this is something affecting the network before the SMG, such as a firewall or IPS. Recently we have seen an increase of these types of cases where the sender uses an SMTP feature called PIPELINING but then does not properly wait for all necessary responses before closing the connection. This causes a protocol violation because the sender does not follow the SMTP protocol properly. These articles are related (even if you are not seeing "Abort" in MAL):
Some messages show "Abort message" in SMG's audit logs."421 esmtp: protocol deviation" and "Abort" action for inbound messages listed in Message Audit LogsYou likely best bet is to audit your network to determine if anything might be interfering with SMTP, as was said previously. Also, it would be helpful to you to reach out to a sender who has had a problem to see if you can get any information on what they saw as the connection failure. They may be able to see a connection deferral such as the "421 esmtp: protocol deviation" mentioned above, or a network connection failure that would help in investigation.
If you are using SMG 10.7.4 or newer, you can also run a tcpdump to capture network packets for further investigation:
TCPDUMP usage on Messaging Gateway 10.7.4 and newer------------------------------
---------------------------------------------
Support Engineer
* Integrated Cyber Defense Exchange
* Messaging Gateway
* Packet Shaper
Symantec Enterprise Division
Broadcom Software
------------------------------
Original Message:
Sent: Oct 04, 2022 02:57 AM
From: Marko Plavsic
Subject: Message Audit Logs shows status as "Processing Status"
Yes, our guy responsible for router is looking for any kind of odd smtp requests... but he did mention something:
"I've noticed that the Symantec does not offer the STARTTLS command.
This might stop some servers from sending mails since they can not be encrypted."
Could this be the issue here?
Original Message:
Sent: Oct 03, 2022 12:26 PM
From: Thomas Anderson
Subject: Message Audit Logs shows status as "Processing Status"
The mail logs on the SMG.
To clarify: the mal log is populated incrementally.
"Wouldn't be less painful if smg tells why conversation isn't completed in the first place?"
I agree: In this case it "looks" like a remote server opened a connection to relay mail to the SMG and then stopped sending data, leaving it listening (i.e. with an active read() outstanding). Again, this is just a guess from what I can see here.
Ideally, under these conditions if/when the read finally times out, the mallog record for the message should have some kind of "connection abandoned" indicator. I know that if it happens in the other direction (i.e. SMG is relaying to the next hop and it closes the connection) the mal entry will have some kind of "abort" indicator.
I'll look into this and see if I can get more information.
In the meantime, I suggest you follow Alexander's suggestion and see if there is any filtering/action going on at the router level, as that could be a root cause of the issue you are seeing.
Original Message:
Sent: Oct 03, 2022 07:37 AM
From: Marko Plavsic
Subject: Message Audit Logs shows status as "Processing Status"
Hi Thomas,
So SMG fills data only when smtp conversation is completed... Wouldn't be less painful if smg tells why conversation isn't completed in the first place?
And where to see/check mail logs? Our exchange is behind smg... so these mails are never accepted by exchange.
Original Message:
Sent: Sep 30, 2022 01:15 PM
From: Thomas Anderson
Subject: Message Audit Logs shows status as "Processing Status"
The article you mention is referencing the "action taken" column in the MAL. In the older release that wasn't getting properly updated.
It is difficult to be certain, but given that fact that the Subject and recipient are not filled in, this really looks like the SMTP conversation was terminated very early. Almost as if, the connection was accepted, got through the "mail from" phase and then dropped before the "rcpt to" completed.
The audit log entries are created and initialized with the audit-id at connection time and then subsequent data is filled in as the conversation progresses, the message is actually accepted and filtering is performed. The "(Processing Status) above is telling you that those fields were never updated because the SMTP conversation never went to completion, hence there is no data to fill in.
My suggestion would be to check your maillogs for instances of connections being dropped before the SMTP conversation completes.
Original Message:
Sent: Sep 26, 2022 05:13 AM
From: Marko Plavsic
Subject: Message Audit Logs shows status as "Processing Status"
Hi,
We have a problem as subject suggests, which I have copied from this link Message Audit Logs shows status as "Processing Status"| Broadcom | remove preview |
| | Message Audit Logs shows status as "Processing Status" | | Issue/Introduction When an SMTP connection is rejected or deferred by Symantec Messaging Gateway (SMG) mail server, the Message Audit Log (MAL) shows its status as "(Processing Status)" for Sender, Recipients, Verdict, Tracker, Delivery, Untested verdicts. This is confusing as the status may not be updated even several hours after the message was processed. | | View this on Broadcom > |
|
|
which suggests that the problem is solved with new version, which we have...
but the problem is still the same...
It is not just with this one domain (which is by the way on good senders list), some goes through some don't. So what is exactly the problem with the ones who don't? Because SMG doesn't say anything which makes sense... And obviously the problem isn't solved with newer version, because it's still there.
Anyone can help?