Windows 2019 și IIS Virtual SMTP Virtual Relay (Office 365)

M-am lovit de un zid cu această configurare și nu îmi pot da seama de asta, în ciuda faptului că am configurat alte câteva servere SMTP virtuale în trecut. Poate s-a schimbat ceva în 2019?

O să vă ofer cât mai multe informații pentru a vă ajuta să mă ajutați :)

Am instalat serverul SMTP și clientul Telnet pe serverul meu din 2019, am urmat ghidurile și am verificat din nou setările pentru a mă asigura că totul este configurat corect.

[General]

• Am permise toate adresele IP nealocate

[Acces]

• Autentificarea setată la „Anonim”
• TLS este închis
• Controlul conexiunii și restricțiile releului setate să permită toate cu o listă goală de mai jos.

[Mesaje]

• Toate au rămas implicite

[Livrare]

Securitate de ieșire

• Autentificare de bază cu numele de utilizator și parola Office 365 setate.

Conexiune de ieșire

• Port TCP: 587

Livrare avansată

• Gazda inteligentă este setată la: smtp.office365.com

Filele [LDAP] și [Security] sunt implicite.

Utilizatorul Office 365 este setat la Autentificare SMTP activată și am confirmat acest lucru prin PowerShell.

telnet 127.0.0.1 25 spectacole:

220 mydomain.com Microsoft ESMTP MAIL Service, Versiunea: 10.0.17763.1697 gata la Mar, 7 Sep 2021 13:53:35 +1000

Cu toate acestea, când încerc să trimit un e-mail prin acest releu, acesta rămâne în directorul C:\inetpub\mailroot\Queue și primesc cele de mai jos în jurnalul de evenimente:

Livrarea mesajului către gazda „X.X.X.X” a eșuat în timpul livrării către domeniul la distanță „recipientsdomain.com” din următorul motiv: Serviciul SMTP la distanță a respins negocierea AUTH.

Probabil că mă voi da cu piciorul după ce îmi voi da seama, dar trebuie să înnebunesc.

EDITAȚI | ×: am uitat sa adaug...

Pot și telnet din rețea către smtp.office365.com pe portul 587 și am configurat, de asemenea, un conector în Office 365 pentru IP-urile WAN care sunt în uz în rețeaua mea.

Mulțumiri! Bil

OK, deci după încă câteva ore de depanare. Am văzut unele solicitări de conectare eșuate în centrul de administrare, care m-au condus pe calea de acces condiționat.

Am avut o blocare a locației configurate anterior în Office 365, așa că am dezactivat-o ca măsură de precauție, dar cred că ceea ce a ajuns să facă a fost dezactivarea setărilor implicite de securitate în azure.

ref: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/concept-fundamentals-security-defaults