Most of my implementations are behind firewalls. However it depends on customer's rules.

If your SMG is behind a general firewall, then it is easy to open only a small hole just for SMTP traffic. Only SMG can use this hole - no other server or workstation.

Some thoughts around the local firewall: if you run SMG appliance then SMG runs its own local firewall to be protected. If you run the new rpm version, then you have to care of your local firewall by yourself.

i approuve fully, Diethmar!

 Greiner Claude 

Like Diethmar Rimser I have SMG behind the firewall but there are some things to think about.

If you have an additional static public IP address you can deploy SMG such that it has direct Internet access and use the firewall as a second line of defence before email enters your private network.

I find it more convenient to setup SMG behind the firewall with a private IP address and have the firewall forward traffic arriving on port 25 to SMG. If you only have a single static public IP address this is really your only option. This way it is easy to deploy a new SMG server with a different private IP address and simply have the firewall forward email to the new private IP address without worrying about changing MX records but there is a downside.

Many firewalls provide content filtering which could be a problem.

I had an issue where a sender complained there was no reply to his email. The SMG Message Tracker confirmed the email was never received. My troubleshooting determined the email contained a virus and the firewall content filtering blocked the email. I wanted SMG to track all incoming email so I disabled the firewall content filtering only on email going to SMG. Now SMG sees all incoming email but I've lost the ability to perform a second independent scan for malware on incoming email. On the other hand, I can use the firewall to block massive attacks from specific IP addresses trying to circumvent SMG's security and restrict or allow incoming email from specific locations using the firewall's geolocation capabilities.

If you really want your firewall to do a second independent scan on incoming email then depending on your firewall's capability, the number of ports it has, and with a little ingenuity, you may be able to send incoming email from SMG back through your firewall before being delivered to your email server.

Kevin, my intention was a open discussion for smg advantage and troubles.  As long customer and integrator i place smg behond the firewall.

But there are many other minds!

Yes, we want no spam or hacker infected emails in our groupwise system, here must the firewall do his job, and then smg

are the implemented dkim, dmarc, spf succesfull or are there troubles / rejected emails? Many providers as microsoft, meta, facebook, google reject emails when this are not corretly configured

And i hear in my network that there are any troubles to solve!

SMG is a complex configuration tool and why not publish your experience to become the best configuration possible!

Exchange experience is better then work alone, we are all humans!

Just a few thoughts in the room

Another thing that really needs to be carefully considered is the rctp-to handling, at which point is this check carried out.

Port forwarding or a D-Nat-S-Nat construct carries the risk that ids / ips are not recognized at the perimeter and the perimeter firewall can react accordingly. Keyword here is exposed host dmz, If S-Nat / D-Nat / Forwarding is used in conjunction with the SMG, can the SMG then block critical networks and IPs via GEO IP or via Abuse Lists or is this better done at the perimeter?

If a DMZ is set up, the question is how exactly the DMZ is set up and what the routing then looks like. Single FW or dual firewall DMZ concept?

At this point I would like to point out possible Arp attacks. Another idea is to work with V-LAN in the perimeter to be able to work even more deeply in terms of security.
If the SMG is set up as a VM and D-Nat/S-Nat or port forwarding is used, what happens if the VM is hijacked and it becomes possible to break out of the VM. If you are working with a Hyper-Visor in a DMZ and a VM has been hijacked, how do I protect iDrac, IPMI, ISCSI and the SAN from further attacks? How do I administer the SMG in the DMZ? Do I have a host on which an HTML5 portal is available which in turn allows access to admin interfaces (Curcamole project)

A further thought could be to set up a bridge between the perimeter and the SMG to allow certain types of network scans to run into the void if I use S-Nat / D-Nat or forwarding. (bridge logic, non promiscous packet analyses)

In somewhat larger networks I may have to set up LDAP-based mail routing, how does the SMG fit into the concept? What if I use load balancers at the perimeter? I haven't said a word about DNS and NameService here; working with DDI and DNSSEC is part of security today. There are now DNS servers that have DDI on board that decide where a service request is “routed” based on the request in order to have more security. In my experience, the question of where the SMG belongs cannot be answered so quickly.


@ Claude

SFP, DIKM, DMRAC, BIMI, ARC and other procedures to make mail secure should be mentioned in the thoughts. What belongs where with regard to these technologies. And then what about certificates that use these technologies.


And finally the question of how to ensure that a mail is not falsified during transport, how do I ensure email integrity?

George

As always, this is my view of things based on many years of experience in IT. If I write nonsense you may forgive me

very good analyze georg! And smg works with postgres database, this must be also secured

nobody speak from all this important things

why do you not work with the ot developers with you know-how?