I've created an internal relay with the Authentication of (TLS, Basic, Integrated Window) and permission of (Anonymous, & Exchange users). So I can receive mail from an entire subnet I've added 10.0.0.0/8 to both servers. When I do this mail will not flow between the two servers, they just build up in the queues, but the example shows that I can and I should be able to. Any ideas To be clear, I've got the connector working, it's only when I try and add an entire subnet that it doesn't work.

On Mon, 18 Oct 2010 18:26:17 +0000, rholland wrote: >I've created an internal relay with the Authentication of (TLS, Basic, Integrated Window) and permission of (Anonymous, & Exchange users). So I can receive mail from an entire subnet I've added 10.0.0.0/8 to both servers. When I do this mail will not flow between the two servers, they just build up in the queues, but the example shows that I can and I should be able to. Any ideas Where are the queues? Are they on the sending (non-Exchange) server? What does the SMTP log on the sending server show as status codes for the commands it sends to the Exchange server? Are the messages your non-Exchange server sends addressed to your domain or to domains that do not exist in your "Accepted Domains" list? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

The queues on the exchange 2010 servers, and the queue name is "smtp relay to remote active directory site" 451.4.4.0 Primary target IP address responded with: "451.5.7.3 Cannot achieve Exchange Server authentication I've run these commands so servers can relay through the connector and they can if I put them in as a single IP. a. Get-ReceiveConnector "Internal Relay" | Add-ADPermission -User "AU" -ExtendedRights "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender" b. Get-ReceiveConnector "Internal Relay" | Add-ADPermission -User "NT Authority\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient" I can telnet and send mail via telnet once the queue starts to build up which is odd.

Add the IP addresses of your Exchange servers to the Default Connector config, or else change your Relay Connector scope to be explicit for the IP addresses you need (rather than entire subnets which include your Exchange servers). Exchange servers can't send to each other using the relay settings. It's a certificate thing. Alexei

you are saying add the remote exchanges servers IP to the default of the other exchange server?

On Mon, 18 Oct 2010 20:27:23 +0000, rholland wrote: > > > > >The queues on the exchange 2010 servers, and the queue name is "smtp relay to remote active directory site" 451.4.4.0 Primary target IP address responded with: "451.5.7.3 Cannot achieve Exchange Server authentication I've run these commands so servers can relay through the connector and they can if I put them in as a single IP. a. Get-ReceiveConnector "Internal Relay" | Add-ADPermission -User "AU" -ExtendedRights "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender" b. Get-ReceiveConnector "Internal Relay" | Add-ADPermission -User "NT Authority\Anonymous Logon" -ExtendedRights "ms-Exch-SMTP-Accept-Any-Recipient" > >I can telnet and send mail via telnet once the queue starts to build up which is odd. So the problem isn't with SMTP relaying, it's sending e-mail between two Hub Transport servers in the same Exchange organization, but in different AD Sites? You don't need any additional connectors for that. What you need to do is identify where the problem is and correct it. Have you run the Exchange Best Practices Analyzer and the Mail Flow Troubleshooter tools? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Yes, that should provide a workaround. Personally, I would go with my other suggestion, i.e. list the IP addresses of the (non-Exhchange) servers that need to relay explicitly in your Relay Connector configuration, rather than specify the entire remote subnet. The problem is that the remote subnet (presumably) includes the Exchange servers located there. This means the Exchange servers will try to use the Relay Connector settings rather than the Default Connector settings. Exchange servers can't work with the relay settings. Alexei

actually the other mail server is in a completely different site with a different vlan, so that's not a problem. The reason I wont to go this route we have 100's and 100's of linux hosts that need to relay through the server, and it would be a full time job just keeping up with them.

Then it sounds like it might be easier to explicitly add the IP addresses of the Exchange servers to the appropriate Default Receive Connectors. You will just need to be aware of this when changing IP addresses, adding Exchange servers, etc. Alexei

So, the mail flow is: Linux mail servers->E2010 HT1 in Site1->E2010 HT2 in Site2 And the messages to Site2 have stuck at HT1 after you changed remote network to 10.0.0.0/8, right? Any update with Alexei’s suggestion?James Luo TechNet Subscriber Support (http://technet.microsoft.com/en-us/subscriptions/ms788697.aspx) If you have any feedback on our support, please contact tngfb@microsoft.com

Linux mail servers->E2010 HT1 in Site1->E2010 HT2 in Site2 - yes this is correct, most of the time we use nail with the linux hosts to send the mail. I tried Alexei's fix but it didn't work. I ran the mail flow troubleshooter and it pointed out that I didn't have an A record or reverse for the replication IP. I'm wondering now if mail is attempting to move down that network. What I mean is I have two nic's and two separate networks, one for mapi the other for replication.

Quote: “I have two nic's and two separate networks, one for mapi the other for replication” So, I assume there’s a DAG in the organization. Could you describe more details about the exchange topology? Please check the output of the all the receive connectors on the HT1 Get-ReceiveConnector | Fl Name,Bindings,RemoteIPRanges Please enable the protocol logging on the receive connectors Understanding Receive ConnectorsJames Luo TechNet Subscriber Support (http://technet.microsoft.com/en-us/subscriptions/ms788697.aspx) If you have any feedback on our support, please contact tngfb@microsoft.com

How's the issue currently?James Luo TechNet Subscriber Support (http://technet.microsoft.com/en-us/subscriptions/ms788697.aspx) If you have any feedback on our support, please contact tngfb@microsoft.com