奇異異常部報告稱，微軟已經成功抑制了一項網絡上的奇怪出現，其中錯誤傳送到 example.com 的流量被引導至一家日本電子電纜製造商。
根據由互聯網工程任務組維護的 RFC2606，example.com 僅供測試用途，任何外部方均不應使用。該域名旨在解決由互聯網編配號管理局管理的 IP 地址，以防止任何非測試域名的意外流量。開發人員和滲透測試人員被建議使用 example.com，以及 example.net 和 example.org，以避免任何無意的意外。
錯誤配置解決，不確定性仍然存在
從終端命令 cURL 中的發現顯示，在微軟的 Azure 和其他網絡中，流量被錯誤地引導至 Sumitomo Electric 擁有的 sei.co.jp 的子域。預期的輸出是正常的，但 JSON 格式的響應中出現了異常，包括：
{"email":"email@example.com","services":[],"protocols":[{"protocol":"imap","hostname":"imapgms.jnet.sei.co.jp","port":993,"encryption":"ssl","username":"email@example.com","validated":false},{"protocol":"smtp","hostname":"smtpgms.jnet.sei.co.jp","port":465,"encryption":"ssl","username":"email@example.com","validated":false}]}同樣地，在 Outlook 中設置 test@example.com 帳戶時產生了類似的結果，這些結果因微軟的自動發現服務而導致流量被引導到 sei.co.jp 的子域 imapgms.jnet.sei.co.jp 和 smtpgms.jnet.sei.co.jp。
UCLA Health 資深網絡安全研究員 Michael Taggart 評論道， 雖然我不是微軟基礎設施的專家，但這似乎是一個簡單的錯誤配置，導致為 example.com 設置的 Outlook 帳戶無意中將測試憑證發送到這些子域。
上週五早些時候，微軟無法解釋此異常並要求額外時間。到週一，問題已經解決，但發言人仍然無法進一步解釋。