Hello and good afternoon. SmarterMail pulls the IP information from the Network Interface details within the Windows Registry. So, the public IP not showing in Settings>Bindings would indicate this server is in a NAT (Network Address Translation) configuration, meaning that the network behind this server is translating public IP traffic to private IP traffic. In this case you'll just want to make sure the bindings are set up on that private IP that is associated with the public address. Lastly, you'll also want to make sure you've opened the appropriate ports in both the Windows Firewall and the Azure firewall configuration areas as well. Please let me know if that helps. Have a good one!

Hi Kyle, thanks for the quick reply, really appreciate it.

Maybe I'm misunderstanding this, I was comparing the SM bindings page with our current setup where we have a standalone VPS (not in Azure).

So maybe I should back up a couple of steps.

I'm planning for the new SM server to be hosted in Azure as the first step of our migration from our existing host. 

I know that Azure initially blocks outgoing port 25, I'm having a dialog with them about that, but I believe incoming port 25 should be open and I'm trying to confirm this.

Let's say the public IP is 1.2.3.4.

I believe everything in Azure is correctly connecting this to the VM.

The NSG and VM WFAS both have incoming 25 open.
From outside, I can RDP to the VM on 1.2.3.4:3389.

But I cannot telnet 1.2.3.4 25

So I moved to testing locally. Within the VM, I can successfully

telnet localhost 25

(and also via internal IP)

but I still cannot 

telnet 1.2.3.4 25

This is what was making me wonder if lack of direct SM binding to this public IP was the difference.

Am I misunderstanding something here?

You're very welcome, happy to lend a hand! Based on your follow-up I do think this is firewall or SMTP blocking related as you're able to reach it from the server itself but not the outside, and your RDP ports are working in the same configuration. Azure does block SMTP by default and I am not aware of a way to unblock it, as Azure typically mandates the use of an Outgoing Gateway. Amazon's AWS however, will allow you to remove the SMTP port 25 block once you have your server set up to meet their requirements: 

Let me know what you find out there :)

Are you saying that, even WITHIN the VM

telnet 1.2.3.4 25

the request would be routed out to the public network and back again, hence affected by firewalls and blocks?

I will check with Azure to see if incoming port 25 should be open, I was sure they only block outgoing.

I'm still curious about the SM bindings page.  Apparently there should be a New button where IP addresses can be added (at your help info link above).  Any idea why it would be hidden in this case?

If 1.2.3.4 is the real (internal) IP of your server attached to the interface, it won't need to go through the gateway and you should be able to telnet to the port.

If 1.2.3.4 is an external IP that is NAT'ed to your server internal IP 2.3.4.5, it will have to go through the gateway and route back.

In that case that means the ports you need to reach on your server have to be forwarded by the gateway/router/firewall doing the NAT.

In the bindings, you will never see your external IP if it's not directly attached to the interfaces. The bindings only shows available local interfaces.
You have to bind the ports on your internal IPs.

That's not specific to SM, it's how network... works, when you're using an internal IP that is mapped externally to an ... external IP.

Kyle, Sebastian, thanks.  Really appreciate the support.

So it looks an Azure restriction after all.  But I thought they still left incoming 25 open by default.

I will follow up with them and let you know how I get on.

You're very welcome, happy to lend a hand! In my experience Azure doesn't allow any outbound SMTP on port 25, and you would need to implement an outgoing gateway to route the email out of the server successfully. I hope this has been helpful. Have a good one!

Hello Kyle,

My problem is close to this. I also have an Azure VM with Smartermail running on it. SM detects in the bindings only the private IP address of the VM 10.1.0.4 and not the public IP address. This seems normal behavior, according to your post and also a Microsoft post that says "Azure VM itself is not aware of its own public IP. The mapping of public IP and the private IP is done by the platform."

Hello Tom! I believe this might indicate a couple of possible issues. While the private IP will show in the logs, it should show up on the remote end as a public IP address assuming the network side of Azure is set up properly. Do you have SPF/RDNS/etc set up for that server and domain already? The command rejected might be due to an SPF failure or something similar instead. If you can submit a support ticket on this we would be happy to help get to the bottom of it for you. Have a good one!