Receive Connector not receiving

Exchange is hybrid o365/on-premises (2016)

From some applications we're getting issues sending (anonymous) emails, specifically 550 5.7.4 "Unable to relay recipient in non-accepted domain".

So, following an article by Paul Cunningham we created a new Receive Connector called it 'Outbound Anonymous SMTP Relay', listing my PC's IP address as a permitted server, with 'Anonymous Users' ticked under 'Permission Groups'.

This has not changed the behaviour, but looking at the logs (following a telnet test) the test email attempt is not being processed by the new Receive Connector, instead it's being picked up by the 'Default Frontend' connector.

What gives?
Jeff JInfrastructure AnalystAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Sunil ChauhanLead AdministratorCommented:
probably you missed something, here are the steps I followed to setup relay in my environment.

http://www.sunilchauhan.info/2016/05/setting-up-anonymous-relay-on-exchange.html
1
Jeff JInfrastructure AnalystAuthor Commented:
Thanks, Sunil

Before I do that, there has been a development.

When I telnet to the on-premises server I get confirmation that I'm connected to the new Receive Connector, then the telnet send test works, but if my manager does the exact same telnet command he gets the 'Default Frontend' connector. If I telnet using one of the aliases we have telnet shows a connection to the 'Default Frontend' connector and fails.

So how is the choice made of which connector will be used? My understanding was that it's like NTFS permissions in that all are evaluated until either one works, or none of them work.
0
Jason CrawfordTransport NinjaCommented:
First I would ensure verbose logging is enabled on your Receive Connectors:

Get-ReceiveConnector | Set-ReceiveConnector -ProtocolLoggingLevel verbose

Is the email address you are attempting to send to external or internal?  Have you added your Manager's IP to the list of RemoteIPRanges?  Please double check you added the 'MS-Exch-SMTP-Accept-Any-Recipient' ExtendedRight to 'NT AUTHORITY\Anonymous Logon':

From the Paul Cunningham article you mentioned:

Set-ReceiveConnector "EXSERVER\Anon Relay EXSERVER" -PermissionGroups AnonymousUsers
Get-ReceiveConnector "EXSERVER\Anon Relay EXSERVER" | Add-ADPermission -User 'NT AUTHORITY\Anonymous Logon' -ExtendedRights MS-Exch-SMTP-Accept-Any-Recipient

Open in new window

Lastly, are you specifying a server FQDN or IP as the relay server or some other value (perhaps a MX hostname) when testing using Telnet?
1
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

Jason CrawfordTransport NinjaCommented:
To answer your question regarding the selection process for Receive Connectors, the answer can be found at the bottom of the article you referenced:

Capture.PNG
1

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Jeff JInfrastructure AnalystAuthor Commented:
First I would ensure verbose logging is enabled on your Receive Connectors:

Get-ReceiveConnector | Set-ReceiveConnector -ProtocolLoggingLevel verbose
Yep, verbose logging is already enabled

Is the email address you are attempting to send to external or internal?
External

Have you added your Manager's IP to the list of RemoteIPRanges?
Yes.

Please double check you added the 'MS-Exch-SMTP-Accept-Any-Recipient' ExtendedRight to 'NT AUTHORITY\Anonymous Logon'
When the telnet tests show a connection to the correct connector the email send works, so I'm assuming (tell me if this assumption is not reasonable) the permissions - applied as per the Powershell commands you showed - are correctly applied.

Lastly, are you specifying a server FQDN or IP as the relay server or some other value (perhaps a MX hostname) when testing using Telnet?
We've tried by the hostname, the IP, and by aliases. A new alias I set up seems to use the correct connector every time, albeit with a small sample so we're trying that 'as live'.

To answer your question regarding the selection process for Receive Connectors, the answer can be found at the bottom of the article you referenced
Apologies for missing that, and thanks for highlighting it.

It's puzzling though, that this isn't the behaviour we are seeing. For instance, with one alias, I get a connection to the correct RC each time I try a telnet test, but when my manager tried it (with his IP address added as an allowed remote sender) he got a different RC.
0
Jason CrawfordTransport NinjaCommented:
If you don't add the 'MS-Exch-SMTP-Accept-Any-Recipient' ExtendedRight to 'NT AUTHORITY\Anonymous Logon', you won't be able to relay email to external recipients.
0
Jason CrawfordTransport NinjaCommented:
0
Jeff JInfrastructure AnalystAuthor Commented:
by:Jason Crawford

If you don't add the 'MS-Exch-SMTP-Accept-Any-Recipient' ExtendedRight to 'NT AUTHORITY\Anonymous Logon', you won't be able to relay email to external recipients.
Agreed, and since I can, this seems to be in place.

by:Jason Crawford

Also, ditch telnet and give Send-MailMessage a try with PowerShell
I will try this, but I've just tried some Telnet tests, just to establish some patterns of behaviour. I've set the Exchange server to respond with the name of the RC that telnet has connected to, with these results:

  • telnet <hostname> 25 : Connects to the new, working RC
  • telnet <FQDN> 25 : Connects to the new, working RC
  • telnet <webmail alias> 25 : Connects to Default Frontend RC
  • telnet <new alias> 25 : Connects to the new, working RC

As I say, I will try the send-mailmessage properly later, but sadly I have a meeting I have to go to.  :-(
0
Jason CrawfordTransport NinjaCommented:
Recreate the RC on all Exchange servers
0
Jeff JInfrastructure AnalystAuthor Commented:
Recreate the RC on all Exchange servers
That's easy, we only have the one on-premise server!
0
Jeff JInfrastructure AnalystAuthor Commented:
Just an update, the problem has, well, apparently just gone away! I think therefore that the problem must have been with the application in question, though I can't see why that would be.

Anyway, thanks all for your help.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Exchange

From novice to tech pro — start learning today.