Mark, Thank you for the input, we will look into traceroutes from outside locations. It does seem to be isolated to Microsoft as we have multiple customers using EOP/O365 experiencing the same problems, but no other customers have reported this issue. The EOP user we are working with also is experiencing the same problem to other destinations as well.
We completed a packet capture to a server that is not behind a load balancer. A message was delayed 15 minutes with the same error message shown in the EOP UI: "450 4.4.316 Connection refused [Message=Socket error code 10061]”. However, there were no connection attempts from Microsoft during that time. There is no RST sent from our hardware to Microsoft. This does seem to narrow the search. There is a ticket open with Microsoft that has been escalated. It’s very slow though, we’re already past the 24 hour mark with no word back, so I’m asking if anyone else has seen this issue. I’m hoping it could help further narrow the search. > On Oct 4, 2018, at 12:37 PM, Mark Milhollan <[email protected]> wrote: > > [mildly rearranged] > > On Wed, 3 Oct 2018, Ryan Krueger wrote: > >> The behavior is that EOP/O365 servers get a connection refused error >> when connecting to our servers. The error is "450 4.4.316 Connection >> refused [Message=Socket error code 10061]...". > >> One of our customer's business partner has opened a ticket at Microsoft >> but experienced difficult and slow support. The support tech simple >> says the other side is refusing the connection, the end. Not helpful. > > And yet that is exactly the issue Microsoft is having in contacting your > system, error code 10061 is WSACONNREFUSED (connection refused), as you > have noted. What more should they report when there's nothing but an > RST returned to them? > >> Our software doesn't have the capability to refuse a connection > > Your software may not but does that include your load balancers? That > they haven't been overloaded might not be the only reason they would > return an RST. I've seen people try to block the prefixes of countries > with which they had no business connections in an attempt to lessen > their SPAM and phishing load only to find out that sometimes SMTP > connections from their customers indeed originated from those countries > -- I'm not suggesting that you've done exactly this, only that something > might be involved in the hosts of the software or the load balancers > where they've been instructed to refuse certain kinds of connections. > > Is there any chance your prefix is being hijacked or poorly sniffed? > Cases where systems other than your MTAs are (also) receiving the SYN > but return an RST because they aren't listening on port 25. > >> Is there anyone at Microsoft that is able to look into this? > > This is indeed what you need, that perhaps nobody else can usefully look > into but you might want to check connections from various places > yourself to see if you do encounter connection problems, e.g., RIPE > ATLAS traceroute, a few hours of VM time from different continents > and/or use of 3rd party monitoring services. > > > /mark > > _______________________________________________ > mailop mailing list > [email protected] > https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
