Cannot receive e-mails from certain domains

Did you already try to look in the logfiles? Maybe some country blocking?

You might want to start with looking in the email logfiles, if those mails are coming to your mail protection at all, then that's the place where you should find them. If not, then look in firewall logs.

Yes I have looked in the log files. They're not reaching my mail server (unless I disable the sophos filtering completely) and nor are they in the sophos logs.

I would have expected to see them in the sophos mail log and the fact I couldn't made me think that it mustn't be my end. However the second I disable sophos email protection the e-mails start coming through which would indicate it is sophos.

If UTM is in transparent mode you should see something in mail log. Even in standart you should see something.

I recomend to use transparent mode if you send/receive emails only from mail server

A better description of how you use mail protection will be helpful

Originally I had the UTM in transparent mode and had a DNAT rule and that worked the same way it currently does. Most e-mails were coming through but those from samsung and mail.ru among others were not. I got the IP addresses involved and put in an exception within the transparent mode which then allowed e-mails from those domains through. However there are various different domains out there and I'm only learning about which ones aren't working sporadically over time. I'd rather put in a permanent solution than keep putting IP addresses in as exceptions.

Currently everything from outside our network passes through the sophos box. Our mail server is on the protected side of the sophos box. We use the UTM to check for spam and viruses and such before it forwards the e-mail to our internal mail server.

I have configured my UTM in SMTP Standard Mode, and it has worked very well.   Others have said that Transparent SMTP should be avoided, without getting into the details of why.

The message sender should be receiving a Non-Delivery Report (NDR) from his mail server, which would be helpful for understanding the problem.

If the traffic is not getting to the mail server when UTM is in the path, then it is obvious that UTM is blocking the traffic, and my experience is that it is doing so because you have told it to do so.   UTM logs nearly everything unless you have told it not to do so.  Each firewall rule can selectively enable or disable logging, so you may need to increase logging detail there, although firewall rules do not normally apply to SMTP traffic.

Are you using ANY Country Blocking?   Since you are having problems with Russia and Korea, country blocking seems like the likely cause.   Configuring Country Blocking Exceptions can be tricky.

See the RULZ post for information on packet processing sequence, which should help you know which log file to search.

See my post in the Management section for a way to parse firewall logs into a SQL database.   I have found that SMTP logs are hard to parse into a form that I consider useful, but I have made some recent progress.  Send a Private Message if this is of interest.

Is UTM your firewall, or do you have a firewall in front of UTM?   If something is in front of UTM, the traffic may be blocked there.

Similarly, do you have any clould-based email filtering in front of UTM?

I have configured my UTM in SMTP Standard Mode, and it has worked very well.   Others have said that Transparent SMTP should be avoided, without getting into the details of why.

The message sender should be receiving a Non-Delivery Report (NDR) from his mail server, which would be helpful for understanding the problem.

If the traffic is not getting to the mail server when UTM is in the path, then it is obvious that UTM is blocking the traffic, and my experience is that it is doing so because you have told it to do so.   UTM logs nearly everything unless you have told it not to do so.  Each firewall rule can selectively enable or disable logging, so you may need to increase logging detail there, although firewall rules do not normally apply to SMTP traffic.

Are you using ANY Country Blocking?   Since you are having problems with Russia and Korea, country blocking seems like the likely cause.   Configuring Country Blocking Exceptions can be tricky.

See the RULZ post for information on packet processing sequence, which should help you know which log file to search.

See my post in the Management section for a way to parse firewall logs into a SQL database.   I have found that SMTP logs are hard to parse into a form that I consider useful, but I have made some recent progress.  Send a Private Message if this is of interest.

Is UTM your firewall, or do you have a firewall in front of UTM?   If something is in front of UTM, the traffic may be blocked there.

Similarly, do you have any clould-based email filtering in front of UTM?

Thank you very much. That has started helping the problem. I turned off country blocking for Russian Federation and that allowed the mail.ru e-mails to come through.

However under my exceptions tab for country blocking I do have the following rule:

Exceptions List:

Region: All regions

Countries: originally it said any or all, but I have changed this to manually list all of the countries instead hoping that would make a difference.

 For all request: going to these

Host/Network: Any

Using these Services: DNS, HTTP(S), SMTP, SMTP SSL and SMTP TLS

I would expect the above rule to exempt country blocking from being used on e-mails. Is there another protocol I'm not including?

UTM is our firewall and we do not have any cloud based mail filtering.

Here are the tricks with Country Blocking Exceptions:

1) The country list

• If the specified network object is internal, you MUST include a country list.
• If the specified network object is external, the country list MUST BE EMPTY.

2) The internal target

When the specified network object is internal, it might be necessary to include both the destination address and the UTM interface address on which it arrives.   I have not tested this enough to be certain, but it is usually harmless to include both.

Examples:

Applying these principles to a Country Blocking Exception for mail.ru:

• You can allow mail from ALL Russian sources by specifying a Country Blocking Exception like this:   
  ToAddress=<MX address>, Target Port=25, Country=Russia.
  
  
• But to ONLY allow mail from the mail.ru email domain requires knowing their IP Addresses.  The Country Blocking Exception will look something like this:
  FromAddress=<mail.ru SPF address list>, Target Port=25, Country=NONE

These exceptions only let the message through Country Blocking.  SMTP Filtering rules will still be evaluated after traffic is allowed past this layer.

You are misleading. Transparent mode is the most protection you can get

In Exception Internal interface is subject only for outgoing trrafic, and will never used for incoming traffic since nobody knows your internal IP's

In general, all dedicated mail servers, internal or external, work with the approach in Basic Exchange setup with SMTP Proxy.   I recommend against using Transparent for anything other than debugging a problem as leaving it enabled means that an infected machine in your network that's a spambot could quickly get you blacklisted.

Instead of 'Host/Network: Any', in the place of "Any," I would use a group of the "(Address)" objects on your WAN port(s).  Including DNS and HTTP/S shouldn't be necessary for this purpose.

Cheers - Bob
PS Moved this thread to the Mail forum.

BAlfson said:

I recommend against using Transparent for anything other than debugging a problem as leaving it enabled means that an infected machine in your network that's a spambot could quickly get you blacklisted.

 

Did you forget on purpose "Who can Relay in the Sytem" Bob?

Host-based Relay

See if I understand the last part of this correctly:

The SMTP Proxy has an "Allowed Relay Hosts" list.  If "authenticated SMTP" is disabled, the devices in the "Allowed Relay Hosts" list are the only ones allowed to send to exterral email addresses.   

In Transparent Mode, UTM is not acting as a relay, so does this mean that the "Allowed Relay Hosts" list is not applicable and not enforced?

Here are some model configurations based on the above:

1) Both modes:  Block incoming SMTP from the outside to non-MX public IP addresses.

DNAT From <Any> TO <Non-MX public IP address list> Port 25 Reconfigure destination as <Dead-End-Address> port 25

2a) Standard SMTP Mode:   Block outbound email not routing through UTM SMTP Proxy

Firewall From ANY to ANY port 25 Action=BLOCK

2b) Transparent SMTP Mode:  Block outbound email form unauthorized internal senders

Need a NAT rule to allow outbound from trusted senders, then a dead-end rule to block all other internal addresses / private IPs.  Not sure I know how to do this.

Is 2B the core of the problem with Transparent SMTP?

I haven't experimented with it in probably 10 years, but I think it allows all internal devices to relay off the Proxy.  Could you test that for us, Olsi?

Cheers - Bob

No for sure. You will get "Relay not Permited"  

And with "autenticated users" (send connector from  exchange with authentication), only Exchange or Mail Program in that computer can send emails, not the computer or the virus in it.

I use in this way not only home, but in my work with 200 devices behind

My colegue plays all days with firewall rules. The only think it is not allowed to do is Mail Protection and our work IP is clean

In transparent mode, you can delete any rule in firewall and DNAT regarding SMTP.  In this way it  becomes Mail Protection, not just a proxy/scanner

In my enviroment:

Under Relay tab I dont have any host. I just have a user in exchange, that is configured in the send connectoe too. The Exchange has no dns configured   too because leaves the email to be handled by. UTM. I can even restart the exchange and not lose incoming mails. Once connected UTM wil deliver spooled emails to exchange, you cant do this in standart mode

The IT nightmare is to get Blacklisted. I can play all the day with Smtp in firewall rules in this way

Douglas you have to skip the internal host from Transparent, after that it will be subject of firewall/dnat rules.

Simple test:  make a rule in firewall to allow a particular host reach any in port 25

Without Skip, telnet anymailserver 25. And see who will respond

With Skip and firewall rule on telnet the mailserver again.

This will clarify you a bit