`sendmail -t`を使用してOffice365アカウントを介してメールを送信できるように、Debianでexim4を正しく設定するにはどうすればよいですか?

`sendmail -t`を使用してOffice365アカウントを介してメールを送信できるように、Debianでexim4を正しく設定するにはどうすればよいですか?

私はDebian Stretch(9.4)を使用しています。

Office365 アカウントがあります。

Evolutionを使用すると、POP3を介してメールを正常にダウンロードし、Evolutionの「Eメール送信」デフォルト設定を使用してメールを送信することもできます。

Server: smtp.office365.com
Port: 587
Server requires authentication TICKED
Encryption method: STARTTLS after connecting
Authentication: Login
Username: <myid@mydomain>

Evolutionを初めて使用したときに、Office365のパスワードを求めるメッセージが表示され、それ以降は問題ありませんでした。

素晴らしいです。しかし:

sendmail -tまた、時にはプログラムを介して電子メールを送信するいくつかのcrontabスクリプトもあります。ここ。パッケージは「スマートホストから送信されたメール、ローカルメールなし」で構成されており、発信exim4-configスマートホストにはsmtp.office365.com::587/etc/exim4/passwd.clientsmtp.office365.com:<myid@mydomain>:<mypassword>

約1ヶ月前まで(6月の最初の週に機能が停止したようです)、このスクリプトはsmtp.office365.comまったく問題なく電子メールを送信していました。ただし、その時点から電子メールを送信しようとするたびに、/var/log/exim4/mainlog次のエラーメッセージがたくさん表示されます。

2018-06-12 22:04:37 XXXXXX-XXXXXX-XX <= <> R=XXXXXX-XXXXXX-XX U=Debian-exim P=local S=2270
2018-06-12 22:04:42 XXXXXX-XXXXXX-XX H=outlook.ms-acdc.office.com [40.100.174.194] TLS error on connection (recv): The TLS connection was non-properly terminated.
2018-06-12 22:04:42 XXXXXX-XXXXXX-XX H=outlook.ms-acdc.office.com [40.100.174.194] TLS error on connection (send): The specified session has been invalidated for some reason.
2018-06-12 22:04:42 XXXXXX-XXXXXX-XX ** <myid@mydomain> R=hub_user_smarthost T=remote_smtp_smarthost H=outlook.ms-acdc.office.com [40.100.174.194] X=TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256 CV=no DN="C=US,ST=Washington,L=Redmond,O=Microsoft Corporation,CN=outlook.com": SMTP error from remote mail server after pipelined MAIL FROM:<> SIZE=3347: 530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM [LO2P265CA0067.GBRP265.PROD.OUTLOOK.COM]
2018-06-12 22:04:42 XXXXXX-XXXXXX-XX Frozen (delivery error message)

Microsoft側または内側の変更があるかどうかはわかりません(私のコンピュータはデフォルトのDebian stable amd64です。動作が停止したときに関連するセキュリティアップデートが適用されたことを覚えていません)。私疑うマイクロソフトは何らかの方法で認証を強化した可能性があり、これを処理するにはexim4構成で何かを変更する必要があります。 (再び強調していますが、Evolutionはsmtp.office365.com:587問題なく同じチャンネルを介してメールを送信しています。)混乱してsendmail -tこの操作をやり直す方法について提案をいただきありがとうございます。

ベストアンサー1

sendmail -tシステム機能を復元しました。

/etc/exim4/passwd.client部分的に調査した結果、エクスポートされたメールが経由して送信されるため、DNS名を一覧表示するだけでman exim4_passwd_clientは実際には十分ではない可能性があることに気づきました。プロセスにはいくつかのリバースDNSルックアップが含まれています。実際、仕事をすることはということから反応を得ます。だから、次の行を含むようにファイルを更新しました。smtp.office365.compasswd.clientping smtp.office365.comoutlook.ms-acdc.office.com/etc/exim4/passwd.client

*.office.com:<myid@mydomain>:<mypassword>

今、すべてが正常に戻ってきました。 (以前は*.office365.comファイルにも実際に1行があることがわかりましたpasswd.client推測するexim4がoffice365.comまたはoffice.comドメインの下のSMTPサーバーに接続していると思うかどうかに影響するMS設定の変更が6月上旬にありました。

もちろん、問題は、Microsoftが以前にHotmailとして知られていたサービスの別のブランド変更を決定し、すべてのDNS名が再び変更されるまでにどれくらい時間がかかるかということです。 ^)

更新 2021-06-10:先週、私のスクリプトのsendmailが信頼できなくなったようです(完全な失敗ではなく、時には問題が解決することもあります)。今;ping smtp.office365.comから応答を受け取り、ファイルに1行を追加すると問題が解決したようです。明らかにAzureインフラストラクチャの一部であるようです。 Microsoftがその方向に動いているようです。何らかの理由で新しい構成がロールバックされると、有効なスクリプトが送信されることがあります。lhr-mvp.trafficmanager.net*.trafficmanager.net:<myid@mydomain>:<mypassword>/etc/exim4/passwd.clienttrafficmanager.net

おすすめ記事