English
Chinese (Simplified)
French
German
Italian
Japanese
Russian
Spanish
Vietnamese
A Mail Server Running Behind a NAT Proxy Device
-
I am about to start testing MDaemon mail server. I am a bit sick of Kerio and appears MDaemon is vastly superior.
I started to read the 937 pages MDaemon manual..........an never ending story.
What I precesily need to understand is the rejection bad emails with forgery in DKIM and non existing domains. Yes, I do understand the principles BUT........... a mail server behind a NAT PROXY ALWAYS see SMTP of SMTPS INCOMMING connections as 192.168.0.1 ( which is the box/gateway address to the outside world).
In particular, Kerio logs always sees the connection from 192.168.0.1 and makes sense. No, I will not put the any mail server EVER on a DMZ.
Looking at MDAEMON manual appears that it might have other techniques in inspecting POST HELO or EHLO for the SMTP service ?
Anyone has any ideas ?
Thanks !
-
Arron Staff
When analyzing the DKIM signature of a message, the IP address it was received from does not come into play. The DKIM signature included in the message is analyzed to ensure that the message body, and any protected headers have not been altered. If you are also checking DMARC, the the receiving IP address could come into play, because one of the methods to be DMARC aligned is by passing SPF for the organization domain of the message. If all messages are being received from 192.168.0.1, then in most cases the messages won't pass SPF and it could impact the DMARC alignment if the message does not have a valid DKIM signature.
I'm not a firewall export and I'm simply sharing this for awareness, If you don't want to configure your firewall like this, its entirely up to you. In most cases firewalls can be configured to allow the traffic to pass to the mail server so that the mail server seeing the actually public IP address the connection is coming from. Doing so can make inbound mail security easier for your mail server.
MDaemon can do SPF lookups on the EHLO value (Security / Security Settings / Sender Authentication / SPF Verification, Apply SPF processing to the HELO/EHLO value). The problem you may run into with this is that many senders do not have an SPF record setup for the value they are passing the EHLO command, althoug the number seems to be growing.
MDaemon can also perform PTR lookups on the value passed in the EHLO command and take action based on the results. (Security / Security Settings / Reverse Lookups, Perform lookup on HELO/HELO domain)
I hope that information helps to answer your question, if not, please provide more details about what you are trying to do.
MDaemon
-
@Arron thanks, you have confirmed my suspections. I can see that many still do not implement things the correct way, even sometims do not understand the precise nature and how DNS work. I used to lecture at a Technical School, Australian Government (TAFE), the Advanced Diploma in Network Security, I am a Cisco Academy trainer and the first thing I used to do was to make sure they knew how DNS work, then we could talk mail server. In those days ARC did not exist.
I run a Fortinet FG40 Enterprise and is a fortress, but as you well said, being behing a NAT/Proxy then good bye to proper SPF.
As a matter of fact in 5 years I have only seen 12 spam messages ending in the hard drive of the server. They (the bad guys) know well how to forge and bypass sometimes. It is just a challenge for me. But if you saw, sometimes the logs on Fortinet you would really dismay. So, I may start the tests with Mdaemon as my current Kerio set up is. What I can see is that product appears vastly superior on paper.
Thanks again and have a nice day.
-
Arron Staff
Let us know if you have any questions.
Thank you, you too!
