locked
Receive connectors not receiving RRS feed

  • Question

  • Using Exchange 2007

    • I've got an Exchange 2007 server which is chosen as the default for services, applications, etc., to connect to via SMTP to send email.
    • A new application requires us to send to individuals not on our domain.
    • The Exchange server won't relay (not a bad thing)
    • I set up a new receive connector for that specific application
    • It doesn't work, and I start troubleshooting
    • Despite several receive connectors having been configured for various purposes, all my testing indicates that none of the receive connectors are actually responding when an incoming connection arrives from a designated remote network / ip address
    • All my testing indicates that the Default receive connector always responds to a request on port 25

    I've tried a myriad of testing, troubleshooting, and reconfiguring, all with no success identifying or remediating the issue.

    Bearing in mind this is a live production server, any suggestions on where to look and/or next steps would be much appreciated.

    Monday, November 10, 2014 5:08 PM

Answers

  • I'd suggest restarting the transport service, but from my knowledge of Exchange 2007, this shouldn't be required.  If you connect from a specific IP address and a receive connector is configured to accept connections only from that address, that receive connector should be handing your delivery.  Apparently that's not what you are seeing, so I'm not sure what is going wrong.
    Wednesday, November 12, 2014 8:36 PM

All replies

  • I just checked this TechNet article on Exchange 2007 receive connectors to be sure I hadn't totally forgotten things:  http://technet.microsoft.com/en-us/library/bb232021(v=exchg.80).aspx

    This says how to allow anonymous relay, and keep in mind that it starts by saying you should configure the connector to only allow specific IP addresses to connect to it.  This is what keeps the server from becoming an open relay.  Now, my guess is that you probably have your receive connector set to allow anonymous connections, but the other two settings were probably not set.  Make those changes, and you should see it working as you expect it to.

    Monday, November 10, 2014 6:30 PM
  • Thank you for your reply.

    I actually referred to Option 1 in the tutorial at {blogs.technet.com/b/exchange/archive/2006/12/28/3397620.aspx} after it did not work as I expected when I configured it.  I have tested the same procedure on another Exchange 2007 server in our organization (which, sadly, I cannot contact from my app), and it did work.

    I don't believe I'm configuring the receive connector incorrectly.  It appears I have stumbled upon a larger problem, in that none of the configured receive connectors (including ones that long pre-date me) appear to be responding.  They all seem to be configured correctly, but in my testing, none are working - except Default, which seems to respond to all incoming requests.


    Monday, November 10, 2014 7:55 PM
  • I guess I've got to ask this sometime - why are you using Exchange 2007 and not Exchange 2010?
    Monday, November 10, 2014 8:40 PM
  • Hi  Bret

    Thank you for your question.

    Did the transport rule limited?

    The Default receive connector is not setup for receiving mail from the internet or from an anonymous connection by default and does not allow anonymous relay. It handles messages between other Exchange Hub Transports and Edge Servers. The more detail you can refer to the following link:

    https://social.technet.microsoft.com/Forums/exchange/en-US/3db2d78b-f558-4ef4-8a83-e4dff7462f9a/understanding-how-multiple-receive-connectors-work

    You can also collect the following logs for troubleshooting:

    1. Get-ReceiveConnect |FL
    2. Collect protocol logging

    If it worked on another exchange server, you can refer to the follow link  for restarting exchange services in order to restart exchange server:

    https://social.technet.microsoft.com/Forums/en-US/4b99e9c4-92ba-4ac3-b821-cc51039559f4/restarting-exchange-server-without-rebooting-what-services-do-i-need-to-restart-is-there-a-better?forum=smallbusinessserver

    You can also refer to the following to create another receive connector and troubleshoot :

    http://www.msexchange.org/articles-tutorials/exchange-server-2010/management-administration/managing-relay-connectors-exchange-server-2007-2010-part2.html

    If there are any questions, please let me know.

    Best Regard,

    Jim

    Tuesday, November 11, 2014 9:42 AM
    Moderator
  • I guess I've got to ask this sometime - why are you using Exchange 2007 and not Exchange 2010?

    Willard,

    I don't believe you've got to ask at all, as, a) the answer has little bearing on troubleshooting the problem I'm observing; b) you should assume that, like every organization, a myriad of political, technical, and financial considerations have prevented such an upgrade from occurring; and, c) you should further assume I'm not going to undertake an infrastructure upgrade in order to solve a niche problem.

    I do appreciate your having taken the time to consider my issue, though.


    Wednesday, November 12, 2014 4:18 PM
  • I apologize - for some reason, I got the idea you were migrating connections from Exchange 2003 to a newer version - I guess I've been reading too many of these questions lately.  Please forgive my mistake.

    And if it helps any, I'm willing to delete it ...

    Wednesday, November 12, 2014 7:06 PM
  • Just a question about your non-responding connectors - are they all configured to accept emails for specific IP addresses, yet when you connect from those IP addresses, only the default connector is responding?  if this is the case, do your tracking logs show that the messages came from the expected IP addresses/servers?
    Wednesday, November 12, 2014 7:10 PM
  • Jim,

    Thanks for taking the time to respond.

    Did the transport rule limited? 

    There are no transport rules currently configured.

    The Default receive connector is not setup for receiving mail from the internet or from an anonymous connection by default and does not allow anonymous relay. It handles messages between other Exchange Hub Transports and Edge Servers. The more detail you can refer to the following link:

    And yet, that seems to be what is happening.

    In order to identify what receive connector was responding, I altered the value of "the FQDN this connector will provide in response to HELO or EHLO" for 5 connectors configured on my server  (5 in addition to "Default" and "Client").  I then attempted to connect to the mail server from various servers and workstations, as defined in the "Remote IP Address(es)" section of the |Network| tab of all 5 of these receive connectors.  All replies to EHLO reply with the "Default" FQDN, not the ones I configured.

    Am I chasing a red herring, or, should I expect to see the FQDNs I configured if the receive connector is responding correctly?

    If it worked on another exchange server, you can refer to the follow link  for restarting exchange services in order to restart exchange server:

    I will try restarting the services after hours, and see if this remediates what I am seeing.

    You can also refer to the following to create another receive connector and troubleshoot :

    I have already created and recreated the new receive connector several times, following various methods found on the internet, and I have never been able to get the server to respond with my custom FQDN, nor relay a message.

    Once again, thanks for your attention and advice.

    Wednesday, November 12, 2014 7:18 PM
  • Willard,

    Just a question about your non-responding connectors - are they all configured to accept emails for specific IP addresses, yet when you connect from those IP addresses, only the default connector is responding?  if this is the case, do your tracking logs show that the messages came from the expected IP addresses/servers?
    Just as an FYI, should it be relevant, I am doing a lot of troubleshooting based on the FQDN that returns when I issue an "EHLO" to the mail server.  I have customized each receive connector (except "Default" and "client") FQDN on the thought that I could distinguish them in this fashion.  I have tested connecting from several servers which should be caught by a receive connector, and none respond with the correct FQDN.  In contrast, on a second 2007 exchange server, the test receive connector I created responds with the expected FQDN.

    When I review my protocollog\smtpreceive logs, I do indeed see the connection arrive from the expected IP addresses.

    Thanks again.


    Wednesday, November 12, 2014 8:00 PM
  • I'd suggest restarting the transport service, but from my knowledge of Exchange 2007, this shouldn't be required.  If you connect from a specific IP address and a receive connector is configured to accept connections only from that address, that receive connector should be handing your delivery.  Apparently that's not what you are seeing, so I'm not sure what is going wrong.
    Wednesday, November 12, 2014 8:36 PM
  • Hi  Bret

    Whether you can find some protocol log?

    If there are any questions, please let me know.

    Best Regard,

    Jim

    Thursday, November 13, 2014 9:43 AM
    Moderator
  • Jim,

    Whether you can find some protocol log?

    I have been looking in the TransportRoles\Logs\ProtocolLog\SMTPReceive folder.  I presume this is the log to which you were referring?  Therein, I see connections arriving from the expected IP addresses, though the log does not seem to specify which receive connector is responding.

    If there is another set of logs which you recommend I also observe, I would appreciate the suggestion.

    I also have scheduled the transport role to be restarted this weekend during maintenance, as per Willard's suggestion, and will check whether this causes a change in behaviour.


    Thanks again.
    Friday, November 14, 2014 6:57 PM
  • Willard,

    I'd suggest restarting the transport service

    Embarrassingly, this seems to have been all that was required.  It never even occurred to me, considering that it should not be required, and that doing so is supposed to involve change control.

    After restarting the transport service, the mail server appears to be replying with the expected FQDN to an EHLO.

    Monday, November 24, 2014 4:20 PM
  • Glad you got it all worked out.  Feel free to mark the associated responses as the answer so other folks will see the solution faster.  (-:
    Monday, November 24, 2014 4:41 PM
  • Glad to hear that it's working!

    In case you are still unable to relay to outside recipients, check out my guide on allowing anonymous relay on a receive connector.

    http://www.youritsource.org/msft/how-to-enable-anonymous-relay-on-receive-connectors-in-exchange/


    Monday, November 24, 2014 5:06 PM