cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4758
Views
0
Helpful
10
Replies

Hop count excedeed issue

Hi,

 

Recently we configured our mailflow to go from Office 365 directly to our CES. Now we are seeing issues with an exceeded hop count. This occurs when CES is trying to deliver the mail to an recipient that is also in Office 365. Somehow the message is directed to our Office 365 and send again to CES. This is repeated untill the hop count reach the max.

When we send mail to a recipient that has another mailsolution, the problem doesn't occur.

What I don't understand is why our CES is delivering the message to our Office 365 and not to the Office 365 from the recipient.

Does anyone know this problem?

Kind regards,
Arjan

1 Accepted Solution

Accepted Solutions

We find out that a misconfigured indeed was the causing the issue. In Office 365 the connector (Inbound from my organization) was configured for checking a cerificate. Because of an error the certificate we use in CES also we hitting the connector... and the mailloop was created.

We modified the connector so that the CES-cerifcate wasn't in scope of the "my organization" connector. With this the mailloop was solved.

View solution in original post

10 Replies 10

UdupiKrishna
Cisco Employee
Cisco Employee

I remember encountering mail loops within O365 environment before. Can you paste output of your SMTP routes and upload/paste the message tracking of email that went through a loop.

Hi UdupiKrishna,

Thanks for your reply! At the moment it looks like the is a misconfigured connector in Office 365. We are currently working that out. Hope that this will solve our problem.

We find out that a misconfigured indeed was the causing the issue. In Office 365 the connector (Inbound from my organization) was configured for checking a cerificate. Because of an error the certificate we use in CES also we hitting the connector... and the mailloop was created.

We modified the connector so that the CES-cerifcate wasn't in scope of the "my organization" connector. With this the mailloop was solved.

Hello, we also have this problem. And we have checked the guide at Cisco and followed it letter to letter. But we also get a loop. Can you point to more exactly were you have issues with the certificate?

Hello Maraz,

The problem was with the inbound receive connector. In some strange way mails from our Cisco configuration to a Microsoft Tenant were received in our tenant again. Our tenant 'saw' that it wasn't mail for one of our users, so it was again forwarded to Cisco. Cisco deliverd it to Microsoft 365... and see there, a loop was created

In the end we discovered that a wrong certificate was used in our inbound connector. With replacing the certificate the problem was solved.

I hope you can quickly solve you problem.

Kind regards,
Arjan

But how can the certificate play a role in this? I do not get it. We solved in another way. On the "Exchange"-side the customer configured, on the outgoing mail rule, an exception when coming from the ESA-boxes. That way we broke the loop.

We don't understand exactly how this happened. Somehow this (wrong) certificate causes that message were received in our tenant. An mail-consultant figured this out for us and solved the problem. I'm happy the problem was resolved, although I don't understand I exactly ;).

We have exactly the same issue, could you pls guide how/where we can create the exception. Our environment have 1 on-prem server, O365 which has inbound and outbound connectors towards onprem and CES. Currently we are having email loop for few domains but not for all. Kindly assist.

Was the wrong certificate in Cisco CES or the inbound-connector? As per my knowledge we don't get the option to assign certificate to O365 connectors.

Hi @sunil-tiwari 
The certificate was configured for the Exchange 365 connector. We didn't make an acception, but correct the configuration in Exchange 365.
Under the inbound-connector (Your org to O365) you can configure how to identity your mailserver. There we configured the subjectname of the certificate that is used by our on-premise server.

Success with fixing the problem!

Kind regards,
Arjan