Smtp proxy outgoing delay

Robert_Vilhelmsen

Hi

Fireware 12.8.2 U2 on FireboxV

I have a Office 365 connector allowing smtp relays from my site. For a long time, i have used a smtp filter, but now changed it to a smtp-proxy. It has Sender encryption required enabled and recipient encryption required enabled. Only TLSv1.2 is enabled.

AV is enabled plus ATP bloker (ATP with standard settings).

Sending out mails containing only text/html goes through the firebox within ms and routed to Office 365. Very fast as expected. As soon as a PDF is attached a mail the firebox takes forever to forward/release the mail to Microsoft´s gateway. Typical aroung 5-10 minuttes.

Here´s what Microsoft O365 log say:
_Message received by: AM7PR10MB3639.EURPRD10.PROD.OUTLOOK.COM using TLS1.2. There was a delay of 9 minutes prior to the message being received by Office 365.
_
Looking at FSM traffic monitor indicates the mail is forwarded instant and disable ATP and AV has no effect.
Why is Fireware so long to forward mails when PDF documents is attached, even with no scanning?

Regards
Robert

james.carson

Hi @Robert_Vilhelmsen
The SMTP proxy is a transparent proxy, meaning it can only stream data (it can't hold it, and send it at a later time.) If APT is enabled and needs to do a scan, the firewall will attempt to idle the SMTP connection, or end it with a connection failure to the sending host in order for the scan to start. The client will usually retry in a few minutes and the scan will have cleared by then.

I'd suggest starting by looking at the logs on the sending mail server to see what it's seeing. If you're seeing multiple connection attempts, the client is likely timing out (or something similar) while trying to send the message.

It's also important to keep in mind that SMTP was never designed to be, nor is it supposed to be an instant communication method. Retries are built to stagger at higher and higher intervals for each failure so as not to inundate/swamp the destination MTA. The 9 minutes is very likely just the next interval the server tries to send at.

Robert_Vilhelmsen

@james.carson

My internal smtp server is set to deliver every 15/30/69/90 minuttes in case of errors. My smtp server logs do not show any errors or re-tries either.
The fact my smtp server logs showed it as delivered and O365 saw delays between 5 to 9 minuttes indicates the issue is at the firebox.

I have just testet again from the same endpoint printer scan with a pdf and today the mails goes through within seconds to O365.

The only difference i see today in the firewall logs is:
2022-12-20 19:13:25 Allow 1.2.3.4 104.47.11.10 smtp/tcp 52325 25 Internal Network External-ACL-21672 ProxyAllow: SMTP File submitted to APT analysis server

Yesterday i did not see the entry for APT analysis even though ATP was enabled, and tried disabled, an re-enabled.

Release messages immediatly when attachments are submitted for ATP blocker analysis is enabled and this is the only feature, i can see could interfear with the communication to the receiver.

james.carson

Hi @Robert_Vilhelmsen
The issue with immediate release is that the SMTP proxy will allow the connection even if the file hasn't been scanned yet -- meaning if something ends up being malicious it'll already have been sent. For outgoing mail, this is far less likely than inbound email, but is still something to keep in mind.

If the firebox does send a file for analysis, it keeps a cache of the MD5sum of that file to speed up subsequent scanning (and ensure dups aren't sent over and over for analysis.)

Robert_Vilhelmsen

@james.carson

@james.carson said:
Hi @Robert_Vilhelmsen
The issue with immediate release is that the SMTP proxy will allow the connection even if the file hasn't been scanned yet -- meaning if something ends up being malicious it'll already have been sent. For outgoing mail, this is far less likely than inbound email, but is still something to keep in mind.

I am aware of this, but the real question is why i did not see the log message SMTP File submitted to APT analysis server the first day when i created the proxy policy.

james.carson

Hi @Robert_Vilhelmsen
Since you did see it the second time, my best guess would be that the firewall's log had already scrolled off or occurred for some reason.

Based off the brief description of the problem, all I can really do is speculate -- if you're looking for a root cause, I would suggest a support case so that the issue can be looked into.