Could not send email to office 365
jason.sherron at microsoft.com
Tue May 14 18:02:49 UTC 2013
I'm an engineer on the Microsoft Office365 Exchange Online ("outlook.office365.com") network team. I'm gathering forensics specific to IPv6 reports -- are people still experiencing IPv6-related issues? I am interested solely in failures that are IPv6 connection issues to "outlook.office365.com".
If you have a clear repro of an IPv6 connection failure, please message me off-list with at least a traceroute. (Please don't deluge me with non-IPv6-related issues -- I'm a network guy working on this one report.)
Jason (dot) Sherron [at] Microsoft (dot) com
From: JoeSox [mailto:joesox at gmail.com]
Sent: Wednesday, May 8, 2013 4:35 PM
To: nanog at nanog.org
Subject: Re: Could not send email to office 365
Just an update if list members are still experiencing this issue. I spoke on the phone with Escalation Manager for Microsoft North America and they had meetings today and their Engineering team is putting a game plan together to roll out a fix for the Outlook connectivity issues. They were debating to roll-out to the group of effected customers or one-by-one. From the data I provided to them it looks like something to do with their NSPI RPC endpoint environment. They told me I should receive a call tomorrow but call them Friday if I do not receive a call. Hopefully, everyone else experiencing this issue is being taken care of as this is the main concern with Cloud services is the lack of response times on major issues.
On Thu, May 2, 2013 at 10:16 AM, JoeSox <joesox at gmail.com> wrote:
> Our Technical Support is reporting a big jump in Outlook connectivity
> issues about 5-10 minutes ago.
> Our resolvers are testing fine.
> Thanks, Joe
> On Thu, May 2, 2013 at 4:53 AM, Joe Abley <jabley at hopcount.ca> wrote:
>> On 2013-05-02, at 02:42, Cathy Almond <cathya at isc.org> wrote:
>> > This may be a red herring, but I've heard of some dropping of DNS
>> > queries for the names within outlook.com domains where the queries
>> > are all coming from source port 53 (i.e. your recursive server
>> > doesn't use query source port randomization
>> ... or there's a NAT or some other box in front of the recursive
>> server which re-writes the source port...
>> > ). Might be worth checking what the recursive server you're using
>> > is doing?
>> > See https://www.dns-oarc.net/oarc/services/porttest
More information about the NANOG