Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 728
  • Last Modified:

Help with exchange 2007 recieve connector

I am installing a new server with Exchange 2007. I have two recieve connectors. one with the FQDN of the internal server (i.e. server.domain.local) and one for the Internet with a FQDN for the public address of the server (i.e. mail.domain.com). When I try to telnet to port 25 on this server from an external location, I get "220 server.domain.local Microsoft ESMTP MAIL Service", when I would expect "220 mail.domain.com Microsoft ESMTP MAIL Service". If I proceed with the test then in response to the "rcpt to" statement, I get "550 5.7.1 Unable to relay for administrator@domain.com". I am interpreting this as the internal connector recieveing external email, but I do now know how or why.  The only clue I have is an error in the event log "Receive connector 192.168.1.1:25 requires Transport Layer Security (TLS) before the MailFrom command can be run, but the server can't achieve it. Check the authentication settings of this connector."

While I have googled this, it does not mean much to me. The implication would be that I have somehow messed up the certificate for the recieve connector, but I do not know if this is correct or how to correct it. I am afraid certificates are a bit of a black art to me!

Can anyone advise/help?

Thanks
Alan

Other information:
The internal connector is set to TLS authentication with Basic, Exchange and Intergrated also ticked. Permissions are all set except partners
The Internet connector is set to TLS authentication and permissions to only anonymous.
0
solplus
Asked:
solplus
  • 7
  • 6
  • 3
1 Solution
 
CuteadderCommented:
in the Exchange powershell...

set-ReceiveConnector "Default **SERVERNAME**" -permissiongroups:"ExchangeUsers,ExchangeServers,ExchangeLegacyServers,AnonymousUsers"

changing **SERVERNAME** for your server name...
0
 
solplusAuthor Commented:
Thanks for the quick response, but having run that, I am still getting response from "server.domain.local" instead of "mail.domain.com" and end up with the message  "Unable to relay for administrator".

The event log yet again has two entries which coincide in time with my test "Receive connector <IP Address>:25 requires Transport Layer Security (TLS) before the MailFrom command can be run, but the server can't achieve it. Check the authentication settings of this connector." One for the real IP of the connector and one for 127.0.0.1.

Regards
Alan
 
0
 
KorbusCommented:
your server needs someway to distiguish between connections from your LAN and from the WAN.  You can assign multiple IP addresses to the NIC, and bind each to a different Recieve connector.

Your router may also be able to alter the port on wich incomming connections are recieved, this would also provide a way to distiguish the LAN vs WAN requests,
0
VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

 
solplusAuthor Commented:
I have. I put the internal network range onto the internal connector and everything else on to the Internet connector! It is either ignoring it or as I have read elsewhere it cannot match the connector with a certificate and so drops through to the default connector. I have no idea how to test/prove this or how to correct it if it is the problem.
Thanks
Alan
0
 
KorbusCommented:
So you are distingushing by the source IP address?  
Thats not really what I meant.  I meant create a new destination IP address on your server, and forward to that IP, all incomming WAN connections (using your router port forwarding rules).
0
 
CuteadderCommented:
is this when your sending from or sending to the exchange server?
0
 
CuteadderCommented:
Another setup step is for the send connector

Organization > hub transport > send connectors
new send connector
*
use mx


address space needs to be * as this will be the domains you send to...
0
 
CuteadderCommented:
and you need to set the accepted domains...
0
 
solplusAuthor Commented:
Sorry, as I said in my initial question, these are my recieve connectors, sending is working fine.
Re Korbus, we are not port forwarding, the server has a public IP which is nat'ed to the internal IP address of the servers network interface.
0
 
CuteadderCommented:
Server Config > hub transport > right click on default recieve connector

change the FQDN
0
 
CuteadderCommented:
as for the 550.5.7.1 error

have you setup the authoritative domains?
0
 
solplusAuthor Commented:
Re: Internal connector FQDN. As far as I can tell the default connectors FQDN is exactly what is should be i.e. ServerName.LocalDomain. What would you have me change it to?

The Internet connectors FQDN is mail.PublicDomain.com. Again, I believe this to be correct, but please tell me otherwise?

Re: "Authorative Domains". Where do I check/set this/these?

Thanks
Alan
0
 
CuteadderCommented:
FQDN example: mail.domain.com like mail.yahoo.com

Auth domain: org config > hub transport > accepted domains > make sure your domains are in there: domain.com or yahoo.com
(atleast it is in exchange 2010)
0
 
KorbusCommented:
"we are not port forwarding, the server has a public IP which is nat'ed to the internal IP "
Wait, so you are forwarding ALL traffic to your mail server?  Not just SMTP,HTTP,HTTPS from the internet?  I dont think that's a good idea, security wise.
NAT providers (weather an ISA server, linux box, or sonicwall device) support port forwarding.

Shot in the dark on why it's not working: the source address you are filtering public vs private on, is being processed as the NAT gateway, rather than the remote server's address.



0
 
solplusAuthor Commented:
Found the answer at Tech Republic (http://www.techrepublic.com/forum/questions/101-242315). Apparently, this happens if you install the SMTP role/service along with Exchange 2007. I had (intuitively) installed this just as I had on all previous versions. When I uninstalled SMTP, inbound mail started working again!
0
 
solplusAuthor Commented:
The link to the solution is give in my previous comment. A description of the reason is given in http://www.techrepublic.com/blog/networking/mail-delivery-and-smtp-changes-in-exchange-2007/389.
0

Featured Post

Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

  • 7
  • 6
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now