Receive Connector precedence

I have a Default receive connector on one of my HT servers that has not been modified since Exchange was installed, all the defaults are still intact (listen on all local IP addresses, receive mail from 0.0.0.0-255.255.255.255, Exchange Servers/Users/Legacy Exchange permissions groups, etc.).

I was trying to demonstrate Receive connectors today and was trying to show how we could create a custom connector that would accept anonymous connections from hosts on our network to submit messages to recipients inside our organization. Sounds simple enough. I set this connector to accept messages only from the range of IP addresses that we use on our Internal networks, permission groups includes only Anonymous Users, and no options are checked for Authentication.

Everything worked as advertised regarding accepting messages from hosts on our network, but it broke inbound SMTP connections from an HT server in another site to this local HT server.. Once I had configured the new custom receive connector, mail would queue up at the remote HT server. When I looked at the SMTPReceive logs on the local HT server (the one to which I added the new connector), I noticed that the connections from the remote HT server was using the new Custom connector instead of Default SERVERNAME like it's supposed to.

It SEEMS like Exchange picked the new Custom receive connector to receive mail from the remote HT server because I defined an IP range in the Custom connector, so it figured that it should override the use of the Default SERVERNAME receive connector. Is this the expected/designed behavior, or should Exchange to Exchange traffic always use the Default SERVERNAME connectors (assuming you didn't modify them)?

My workaround was to take the block of IP addresses for our entire network out of the accepted IP addresses. Then, add in several subnet blocks individually, not including the address of the remote HT server. Once a range of addresses that didn't include the remote HT server was input into the receive connector, mail flow was fixed, and the stuff from the remote HT came in using Default SERVERNAME.

Any thoughts?

Thanks,

blargoe

Find more posts tagged with

Comments

royal

I always create an Internet Receive Connector for Anonymous Mail. I then leave the Default Receive Connector alone. I wouldn't really mess with the Receive Connector as it typically breaks things internally. For example, if you assign a custom FQDN to the Default Receive Connector, HUB to HUB will fail. You can only have the FQDN either blank, NetBIOS, or NetBIOS.FQDN.com.

Assigning an FQDN to an Internet Connector is just fine. It's one of the main reasons why I create them.

So for internet mail, use an Internet Receive Connector. For internal HUB to HUB, use the Default Receive Connector. For POP3/IMAP4, use the Client SMTP connector which uses port 587.

Also, connects always use the most explicit settings. So any time you specify an IP address over All IPs, it'll use that no matter what. It's actually the way you allow relaying to be secure. You create a custom connector, assign Anonymous, then add permissions in AD to allow the Anonymous Group to relay using that connector. The IP that you want to relay, you assign to that connector and that way, that Server will always use that connector because it's the most explicitly defined and be granted the ability to relay.

blargoe

I was hoping you'd reply royal. I always appreciate your feedback.

I must not have been clear when I typed the first post, the Default connector hasn't been modified at all, nor did I add an FQDN. It was just that the act of adding a new connector caused Hub to Hub to fail.

Also, connects always use the most explicit settings. So any time you specify an IP address over All IPs, it'll use that no matter what.

That must be why it broke... I wasn't expecting for Hub to Hub to ever deviate from the Default connector. I was also thinking that Hub to Hub required TLS, and the new connector didn't have TLS, which is another reason why the behavior surprised me.

Side note - I actually do have another separate Internet receive connector defined on my HT servers based on a suggestion from you when I was first getting started with 2007. That has been working great from day 1

BTW, here's the connectors that I have in place on the server in question

Client SERVERNAME - configuration has not changed since installation
Default SERVERNAME - configuration has not changed since installation
Internet Inbound Mail - accept connections only from the Internet IP's of the Exchange Hosted Services datacenters that we use, TLS authentication is offered, anonymous users permission group is checked
Internal Application Relay - accepts connections only from IP's of a couple of internal servers that must relay to external domains, Externally Secured option is check so that the accept-any-recipient permission is applied

Internal SMTP Submit - this is the new one that I started the thread about, when I put in our entire internal IP block (say 10.10.0.0/24) as accepted, that hosed up Hub to Hub connections. The remote Hub used this connector instead of Default.

I guess technically I could just use my already existing Internet connector for my internal servers that need anonymous access, but I'd still have to add subnetworks to the connector in a way that doesn't include the address of my Hub servers or I'll see this happen again. When I started with this, I was just wanting to add our entire internal network to a connector so I wouldn't have to go back in the future and add addresses later. But the Internal block is more explicit than what's defined by default in the Default SERVERNAME connector, so Hubs would end up using this connector instead if I left the whole block of internal addresses in there.

So just to clarify, when an SMTP connection is made from any host to a Hub server, the Hub server looks at the sending host's IP, compares it to the allowed addresses on each connector (giving precedence to a connector that is more explicit by way of either a defined allowed IP range or an IP address) and that is how it makes the determination on which Receive connector to use - permissions aren't considered at all in the process of PICKING a connector? Permissions only come into play once a connector is picked and the SMTP conversation is started?

Thanks for helping me understand that. All the training I've been to and I've never heard that or don't remember it anyway

royal

Hub to Hub does not require TLS. It uses something called Opportunistic TLS. A receive connector will offer StartTLS and the Send Connector from the other HUB will allow for this to happen because the Get-SendConnector -IgnoreSTARTTLS is set to $false; which is default. The only way to absolutely require TLS to occur is by doing a Set-ReceiveConnector -RequireTLS:$true. If you want to ensure you are using TLS, the way the TLS system works is by determining if the Receive Connector FQDN/NetBIOS name is in the certificate. If it is, it will use that certificate to utilize TLS. If it's not, it reverts to the self-signed certificate.

I go into this a bit in my article @ http://www.shudnow.net/2008/11/08/exchange-2007-mail-flow-dns-records-connectors-and-tls/. Because of this, it's generaly recommended to have your Internet Connector FQDN in your certificate which matches your MX record. It's also recommended to have your Default Receive Connector FQDN in your certificate. This way all TLS is ensured to use that certificate and you can just delete your self-signed certificate since both FQDNs will use your new certificate for TLS.

There's a simple solution for you I think, add the entire subnet to your custom connector and modify your default receive connector to specify the specific IPs of the other HUBs. That way, the Default Receive Connector is now the connector that is more explicit.

blargoe

Maybe I'll do that, just do the IP's of the Hubs in the Default connector. I've had it so ingrained in my mind to not modify the Default connector that I really didn't give it consideration as an option... but how often really am I going to be moving an Exchange server or adding a new one now that the org is up and running?... Not often, so it should be fine as long as I remember what I did, while threatening blood if others come in behind me and make any changes to it. Just add it to my SOP for adding a new transport server in the future.

The TLS cert is OK, another part of the reason why I did a dedicated Internet connector was so that I COULD define a custom FQDN for the Internet email from EHS to match an existing cert that I had.

Thanks royal. Much appreciated.

blargoe