Passing SMTP (Non-Web) Traffic Based on Domain

[soccerextreme]

I know I can pass certain SMTP traffic based on the source address, but can I do it based on a domain? For example, Threat Prevention automatically blocks SMTP traffic coming rom iCloud servers (i.e. *.icloud.com and *.me.com), so is there a way I can blanket permit domains like that?

All I can think of to do is base a rule on a condition category like HTTP:URL, but I get the impression that it will only affect web-related traffic.

[sky-knight]

Threat Prevention isn't designed for protecting servers. I'd have ingress services of any kind, much less SMTP routing into a dedicated rack that lacked that module entirely.

There is no "domain" on an incoming session, there is only an IP address. There's no HTTP(s) request to read, just an incoming TCP session with SMTP in it. So you're stuck trying to whitelist ingress IP addresses which eventually will invalidate the module entirely.

Use your policies correctly, get ingress services into their own racks designed to protect them with stuff that's good at that specific traffic, with rulesets to match. Threat Prevention has no place here.

[soccerextreme]

@sky-night, after talking to Untangle Support they indicated that it should work for filtering/protecting SMTP traffic. However, they indicated that they're just seeing it block a lot of false positives, and that they hope it'll be better in the near future. So I'm just going to turn it off and check back on the product later.

[soccerextreme]

I figured I would update this thread with some of the progress I've made using Threat Prevention with internal SMTP servers. Here's my main takeaway so far.

Most of the false positives that TP blocks do not have a Client Address Category associated with them, therefore creating a rule that ignores/passes any SMTP traffic that isn't explicitly categorized seems to aid greatly in preventing TP from blocking legitimate email traffic. I've been monitoring the logs and I've also found that some sources that are categorized as Windows Exploits and Reputation also contain a lot of false positives. Therefore I've made a rule that looks like this in TP.

TP Rule.PNG

So far the only false positives that I'm seeing now are a handful of icloud.com/me.com and Gmail servers, which eventually try again from other unblocked servers (i.e. the email still eventually gets through in a timely fashion). I'm continuing to monitor the situation to see if this configuration will suffice, because it's nice to have the additional layer of SMTP protection from services like TP. I've made a custom report that shows me all blocked SMTP traffic too so that I can track down any lingering false positives if I need to.