うちの会社はすべてに.localを使ってたんだ。その時は普通だと思ってたけど、VMWARE製品で問題が起きてからは違うって気づいた。サポートが根気よく.localは他の目的のために予約されてるって説明してくれて、Wikipediaのリンクも教えてくれたけど、彼らがドキュメントやトレーニング、ウェビナーで.localを使ってた理由には一切答えてくれなかったよ :)

それって、予約される前から人にそうするように言ってたんじゃない？そうだとしたら、広く使われているものを「予約」できないっていうのが問題だよね。mdnsは.mdnsみたいな別のものを使うべきだった。.devがgTLDになったときみたいに、見栄と金儲けのために多くの設定を壊してしまったんだ。エンジニアリングの面では明らかにミスったね。

.localの使用はADよりもmDNSの前からあったんだよね。そのアドバイスはmDNSが登場してから「corp..」に変わった。

.exampleはexample.comよりずっと安全だと思うよ。https://www.akamai.com/blog/security/autodiscovering-the-gre... それによると、もし誰かがautodiscover.comを登録したら、autodiscover.example.comがないexample.comはOutlookがautodiscover.comにエントリーがあるか確認しようとするみたい。ほんとに頭の悪いシステムだよね。

楽しいことばかりじゃないよ、ドーナツが.tmptestを買ったりしたらどうするんだろうね。

ちょっと待って、.tmptestのgTLD申請の書類を出してくるね /s

それって本当にこの場合に影響あるのかな？これはマイクロソフトの発見サーバーの設定ミスやバグだし、「不明なアドレスにはこの.jpアドレスを返す」みたいなフォールバックがあってもいいと思うんだけど。

まあ、この特定のケースでは明らかに悪い選択が悪化させてないってだけで、それが良い選択だとは限らないよね。「ああ、欠陥トラックは高速でハンドルを握っている人にだけ怪我をさせるけど、俺は高速でハンドルを握ることなんて気にしないから、YOLOで大丈夫」みたいな感じ。もし人々がIANAの予約済みTLDを使っていたら、Windowsが例えばautodiscover.exampleに接続しようとしてもポリシー上存在しないから、試みは常に失敗するから影響を受けなかったはず。

それで100k通のメールを送信したら、全部バウンスして、メールサービスが停止されるんだ…

他の人も指摘してるけど、'tmptest'を使うのは、誰かがtmptestを買うまで有効だよね。まあ、あり得ないけど、最近は何でも売れるからね。俺はいつもISO-3166の「ユーザー指定」の2文字コード（AA, QM-QZ, XA-XZ, ZZ）を使ってる。ISO-3166メンテナンス機関がそのコードを通常の国コードに戻すための国際的合意を得るのに、宇宙の熱的死よりも時間がかかるだろうって理論だから、内部ドメインに使うのは多分安全だと思う。

うん、意図的に使うっていうよりは、安全ネットみたいな感じだね。

彼らはログインしてIMAPの設定を逆解析しようとしてるんじゃないかな。

curl -uはフィールドがあるだけでいいと思う。認証は行われないから、どんなパスワードを送っても出力は変わらないよ。

同じような質問への返信をここで見てみて（まだ見てなかったらね）： https://news.ycombinator.com/item?id=46732623

思ってるより一般的だよ。少なくとも、マルチアカウント同期やスケジュール送信の機能を実現するために、認証情報をサーバーに保存する人気のメールクライアントを知ってる。

今のOutlookって、ほぼSaaS製品みたいなもんだよね。

そうだね、誰も気にしてないと思う。何年も前に、スマホにファイアウォールをインストールした時、Outlookが自分のプライベートメールサーバーに全然接続できてなくて、代わりに自分の認証情報をクラウドに送って、そこからメッセージをダウンロードしてるのに驚いたのを覚えてる。あの頃、ランダムにクラウドサーバーにアクセスしないAndroidのメールクライアントはK-9 Mailだけだった。

そうだね、Windows 11の2023h2アップデート以降だよ。

それだけじゃなくて、新しいOutlookアプリはMicrosoftをあなたのメールアカウントの完全な中間者にしちゃうよ。https://www.xda-developers.com/privacy-implications-new-micr...

基本的に、マイクロソフトが作るHTTPに関わるものは、基本認証を要求するサーバーにあなたのユーザー名とパスワードを送信するんだ。Microsoft Edgeには2020年か2021年にこれを無効にする機能が追加されたみたいだけど、今はデフォルトじゃないし、グループポリシーも直感的じゃなくて、暗号化されていないHTTP接続にしか適用されないんだよね。

ちょっと待って、これってOutlookアカウントを設定しようとすると、Microsoftにフルクレデンシャルを送信するってこと？「Outlookアカウント」だけじゃなくて、Outlookのデフォルト設定であればどのアカウントでも。俺はメールサーバーを運営してて、自分用がメインだけど、友達も何人かアカウント持ってるんだ。で、少し前に友達がロックアウトされたって報告してきて、原因はOutlookのバージョンを切り替えたせいで、ホワイトリストが期待してたアドレスとは全然違うアドレスに接続してたことが判明したんだ。しかも、その時はOutlookを使ってなかったのに。アクティブな接続はその友達の操作がプロキシされてたせいだし、IMAPのクレデンシャルも保存されてたから、MSサーバーが好きな時にログインしてチェックできる状態だった（多分、意図されてるのは、メールを使ってない時でもスマホやデスクトップに新着メールの通知を送れるってことだと思う）。> でも、これはセキュリティやプライバシーの期待を壊してる気がする。確かにそうだね。この挙動はある程度抑えられるけど（最近の変更がなければ）、新しいOutlookのバージョンではデフォルトで完全に有効になってる。上記の友達は、俺が「MSが運営するどんなホストにもホワイトリストを開放したくない」って言ったから、急いで他のサービスにメールを移行したんだ。彼は「ローカル接続のみ、クレデンシャルをどこかに送信しない」っていう以前の挙動に戻す方法を探りたくなかったみたい。

ずっとそうだったよね。

curl -uスイッチはパスワードフィールドが埋まってればいいだけだと思うけど、test@example.comっていう正当なユーザーアカウントはMicrosoftにも日本のIMAPサーバーにも存在しないよね。

ドメイン自体じゃなくて、MS Office Cloudでの登録が問題なんだよね。example.comのメールの所有者を調べると、その会社が出てくる。

彼らが最初にexample.comをOutlookアカウントに追加しようとしたユーザーだったんじゃないかな。で、マイクロソフトがそのドメインの所有を確認せずに割り当てちゃったんだと思う。

この場合、「null MXレコード」っていうのはMXは存在するけど、有効なサーバーを指定してないってことだよ：$ host -t mx example.com 例として、メールは0で処理される。送信者はこの場合、Aレコードにフォールバックしちゃダメだよ。