APT slow on port 993

toscanatlc

Greetings,

we have several accounts in imap, we also have APT enabled on the port 993 policy, we often find ourselves having to synchronize very full mailboxes on other email clients, scanning and synchronization is very slow and sometimes it hangs due to timeout, disabling APT everything come back ok, does anyone know I have a way to speed up the APT scan or some trick?

Thanks Cistiano

james.carson

Hi @toscanatlc

APT Blocker will effectively stall the SMTP connection while a scan is being performed in order to complete the scan. APT effectively unpacks files that it supports and attempts to run them to determine their behavior. MD5sums of previously scanned files are kept cached on the firewall in order to speed up subsequent scans. but there isn't a way to speed up the scan itself.

APT does this to prevent infected mail from reaching the client while it's scanning. Since the firewall is doing proxy based scanning (as in it's not a full-blown MTA) this is the only way it can prevent that mail from delivering until the object is scanned.

toscanatlc

Hi James,

I know very well how the APT works, I've been using it for years now, but lately it seems to me that it has slowed down a lot, I was just asking for some best practices to implement speed a bit if possible.

Thank you

james.carson

The best I can suggest here:

-Don't use APT on mail outbound from your system. Anything headed out will have already been scanned by your desktop A/V and is likely considered clean.

-APT scan on inbound mail as it is delivered to your mail server if possible (you can use a SNAT action to deliver it to a cloud service, if your mail server is not on-premise. This scans the mail when it arrives vice it scanning when the customer is waiting to download it. What I believe is happening based on your description is when the customer tries to download mail, they're getting stopped multiple times because
1. they're getting APT scans on multiple files, and
2. Multiple users are likely checking their mail at the same time, meaning all of them trying to scan at once creates a bit of a queue.

Beyond that, if you'd like to investigate speed of queueing/file detonation, I would suggest a support case where we can get details on the firebox involved, the amount of traffic being sent to APT, and scan times. In general, APT scans shouldn't be taking longer than 5 minutes to come back, and will often come back in less than a minute.

toscanatlc

Hi James,

can you explain this to me better: ?

APT scan on incoming mail as soon as it is delivered to your mail server, if possible (you can use a SNAT action to deliver it to a cloud service, if your mail server is not on premises. This scans mail when it arrives scan when the client is waiting to download it.What I believe is happening based on your description is that when the client tries to download the mail, it gets interrupted multiple times because 1. it receives APT scans on multiple files

james.carson

@toscanatlc

Ideally, scanning mail before it's being delivered to your mail server allows it to be scanned, queued, and stored before the client needs to access it.

The flow would look like this inbound:
Internet -> SMTP proxy w/GAV/APT -> Your Mail Server -> Your mail users.

and like this outbound:
Your mail users -> Your mail server -> SMTP proxy w/gav/apt -> external users

Based on your description of users having to abort/retry connections, it sounds like your flow is

Internet -> Your mail server -> Proxy (potentially IMAP/SMTP/POP3) -> Users
and
Users -> Proxy (IMAP/SMTP/POP3 -> Mail Server -> Internet

Doing it this way causes the client connection to be the one waiting for the scan, which creates the noticeable stalls from the user's perspective.

If you're using a cloud service like Office 365, you can use the SMTP proxy to scan mail before it is delivered to your cloud service, too.
https://www.watchguard.com/help/docs/help-center/en-US/Content/Integration-Guides/General/Office 365_Firebox_SMTP.html

toscanatlc

Thanks James!!