Trying to grasp Exchange 2010 connectors..
Hi All, I'm trying to get to grips with how our Exchange setup has changed, migrating from a 2003 to 2010 environment (we had a 3rd party do it). Email outbound out of our Domains is sent via a smarthost. I've 3 Hub transports: Client - port 587, no IP restriction, Auth: TLS, Basic_only_after_TLS, Integrated Windows Auth, Permission groups: Exchange Users Default - port 25, no IP restriction, Auth: TLS, Basic, Exchange Server, Integrated Windows, Permission groups: Anonymous, Exchange Users, Exchange Servers, Legacy Exchange Servers Re-injection I understand Re-injection. I'm ok with how that works. What I'm trying to understand is local clients that aren't Outlook, and how they connect, authenticate/relay, and how that applies to the above transports. From my testing, it seems that a local client can send email in using port 25, but that unless its authenticated, it can't relay out to other domains via the Smarthost. It they authenticate then they can relay outbound via the Smarthost. I'm missing how Exchange knows if an inbound connection can relay or not. Any help anyone can give ?
July 27th, 2011 10:46am

The "Client" receive connector now serves the purpose of handling client requests. You should have your non-MAPI clients reconfigure to use port 587. The reason for this is that it's easier to separate the relay function when you use a different port, and much easier to keep your Exchange server relay secure. You can certainly configure the "Default" receive connector to work the old way, but you may want to consider not doing that for the reason I just shared.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
Free Windows Admin Tool Kit Click here and download it now
July 27th, 2011 11:09am

That's not considered relay since it's internal recipients, once you try to send to external that's considered relaying. If your application server or devices like copiers need to send mail only to internal recipients – mail for which Exchange has an AcceptedDomain (or a Recipient Policy in Exchange Server 2003/2000) and therefore will receive inbound mail for – it is not considered relaying. The application server or device should be able to do this without any configuration on Exchange. Exchange Server 2007: How To Allow Relaying http://suneja.com/2007/01/exchange-server-2007-how-to-allow-relaying.htmlJames Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
July 27th, 2011 11:13am

Hi Guys, Thanks for the response. I have a complete mix of old machines that can only use port 25, and modern clients (Thunderbird etc) that I can reprovision, as well as the main base of Outlook 2003/07/10 clients. So I know 587 is the "new" port for internal clients to ideally use. I suspect most of my SMTP clients are still using 25 though. What I'm not understanding, is the mechanism Exchange is using to deny-relay to the external smarthost. So - if I send an email to anyone@anywhere.com, and I connect using anonymous credentials on port 25, that would be the Default Connector handling it... but how does it know to block that message? If I connect using an Authenticated user, then the email is sent, but its still the same connector right ? I'm just writing out a list of SMTP connection settings and tests so i can get my head straight around this. And I'll take a look at that 2007 document to see if that helps too.
Free Windows Admin Tool Kit Click here and download it now
July 27th, 2011 12:51pm

So - if I send an email to anyone@anywhere.com, and I connect using anonymous credentials on port 25, that would be the Default Connector handling it... but how does it know to block that message? If I connect using an Authenticated user, then the email is sent, but its still the same connector right ? Yes Default connector, it blocks it because "externally secured" is not checked in the authentication tab. Since this is not checked you're basically saying you don't trust these machines. For mapi clients they would be using the Client connector and mapi clients are inherently authenticated. Now if you use a application and authenticate it will still use the default connector but would be able to send since it's authenticated. It's always best to create a separate relay connector to handle your apps rather then configuring your default connector. Allowing application servers to relay off Exchange Server 2007 http://blogs.technet.com/b/exchange/archive/2006/12/28/3397620.aspxJames Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
July 27th, 2011 1:06pm

A couple of things. THe Default connector doesnt allow anonymous connections unless you enable it. Its really there for hub to hub/ hub to edge communication. Mapi Clients do not use these connectors at all
Free Windows Admin Tool Kit Click here and download it now
July 27th, 2011 1:27pm

My bad, Andy is right mapi doesn't use the connector, it's submitted directly to the store. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
July 27th, 2011 1:35pm

I recommend that you have your POP/IMAP clients change their sending port to 587 rather than trying to make the receive connector work. Alternatively, you could create a separate receive connector with a different IP address and configure it as a "client" receive connector.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."
Free Windows Admin Tool Kit Click here and download it now
July 27th, 2011 1:50pm

Mmm.... Externally Secured isn't checked in either of my connectors.. so not quite yet seeing how relays working. But let me finish reading that document..
July 28th, 2011 4:15am

It's not supposed to be checked, by unchecking it it doesn't allow untrusted relay.James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com
Free Windows Admin Tool Kit Click here and download it now
July 28th, 2011 10:19am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics