Dovecot + Postfixを使用して、Linux上でIMAP + SMTPサーバーを実行しています。サーバーはTLS経由の接続のみを受け入れ、トンネルが確立されるとプレーンテキスト認証を使用します。
今日、メールログを監査していて、一部のIMAPログインで表示される不明なリモートIPアドレスが心配でした。調査の結果、ログインがOutlook for Androidクライアントに対応していることがわかりました。
ログインが正当であることに私は満足しています:
リモートIPはブロック内にあります:
52.125.138.x
52.125.140.x
52.125.141.x
ログエントリは次のようになります。
dovecot: imap-login: Login: user=<...>, method=LOGIN, rip=52.125.x.x, lip=x.x.x.x, mpid=x, TLS, session=<...>
したがって、私はOutlookモバイルクライアントが中間サーバーを使用するように設計されているとしか想定できません。
おそらく、これは、MSサーバーが実際のメールサーバーをポーリングし、電話にプッシュ通知を送信できるようにすることで、バッテリー寿命を節約するためです。
ただし、私の知る限り、これはMicrosoftがユーザーの資格情報を中間サーバーにプレーンテキストで(少なくとも一時的に)保存する必要があることを意味します。
資格情報を共有せずに、クライアントデバイスではなく独自のサーバーからTLSトンネルを介して認証している可能性はありますか?
これは、中間サーバーがメールをクライアントにプッシュする前に読み取ることができることを意味しますか?
この動作は文書化されているか、既知ですか?
pS他の人はこの振る舞いに気づいたようです:
- 資格情報を共有せずに、クライアントデバイスではなく独自のサーバーからTLSトンネルを介して認証している可能性はありますか?
いいえ、サーバーが接続を確立するには、資格情報を知っている必要があります。そして、クライアントではなくサーバーが接続を確立していることを知っています。これは、Android Outlook 3.0.46(315)を実行しているタブレットから送信されるすべてのパケットをキャプチャし、それらのパケットはまったく送信されなかったためです。構成されたIMAPおよびSMTPサーバーですが、かなりの数がMicrosoftアドレスに送信されました。それらのメールの要塞がHTTP CONNECTプロキシのように機能したとしても、サーバーからのTLS証明書が表示されるはずでしたが、そうではありませんでした。
同様に、私がメールをサードパーティに送信したとき、最初のホップのメールサーバーはmail.Outlook.comでした。これは、メールサーバーを認証して、メールを送信する必要がありました。これは、受信者が確認するSMTPヘッダーのすべてです。
つまり、クライアントがトンネリングするのではなく、接続を行うサーバーです。そしてそれは、たとえ一時的であっても、彼らのサーバーがあなたのパスワードを知っていることを意味します。
- これは、中間サーバーがメールをクライアントにプッシュする前に読み取ることができることを意味しますか?
はい、そうです。
- この動作は文書化されているか、既知ですか?
それを言うのは難しいです。彼らのバンドルされたドキュメントは私が見たものを明確に説明していませんが、そこには驚くほど多くのドキュメントがあります。
この動作には正当な技術的要因があることは注目に値します-デバイスが移動する可能性のあるさまざまな電話およびワイヤレスネットワークがメールサービスへのアクセスをブロックする可能性があります。これは、イングレスフィルタリングがこれまで成功した唯一の分野です。ホームベースのマイクロソフトを介して通信を強制することにより、メールプロトコルがソースでブロックされないようにすることができます...
...それがあなたにとって価値があるかどうかは別の質問です。