Domena dodana do Microsoft 365 / Office 365 nie zgłasza problemów z konfiguracja, świeżo zakupione licencje, działająca poczta w usłudze Exchange… i dziwny problem z wysyłką wiadomości poprzez SMTP. Błąd klienta/skryptu czy formularza web sklepu informuje o problemach z uwierzytelnianiem lub podaje poniższym komunikatem:
The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROMMy jednak jesteśmy pewni swoich ustawień, loginu i hasła. Microsoft podaje kilka sposobów na realizowanie wysyłki wiadomości za pomocą SMTP. Te rozwiązania to proste włączenia samej usługi na skrzynce aż po uruchomienie konektorów + odpowiednie wpisy SFP do domeny. Jeżeli jednak pomimo w/w czynności nadal macie z tym problem, kiedyś już u kogoś to działało! Microsoft mówi ze to musi działać! Czas zatem na sprawdzone rozwiązanie.
Zacznijmy jednak od początku, kiedy pojawiają się problem z SMTP? W końcu sprawdziliśmy już ustawienia klienta czy naszego skryptu i powinny one zawierać:
Nazwa serwera IMAP: outlook.office365.com
Port IMAP: 993
Metoda szyfrowania IMAP: TLS
Nazwa serwera POP: outlook.office365.com
Port POP: 995
Metoda szyfrowania POP: TLS
Nazwa serwera SMTP: smtp.office365.com
Port SMTP: 587
Metoda szyfrowania SMTP: STARTTLSLogin i hasło tez działa bo możemy dostać się do konta poprzez www. W dodatku wiemy że bez problemowo możemy wywołać telnetem serwer SMTP na określonym porcie z naszej sieci.
Microsoft Telnet> open smtp.office365.com 587
Connecting To smtp.office365.com...
220 AM6P191CA0010.outlook.office365.com Microsoft ESMTP MAIL Service ready at Wed, 6 May 2020 01:55:17 +000Czyli nie problem sieciowy. Z powodzeniem działa nam odbieranie po IMAP w Thunderbird, czyli klienta skonfigurowaliśmy poprawnie. Zalogujmy się wiec na panel administracyjny samej usługi Microsoft 365 / Office 365, wybierzmy konto z którym mamy problem i sprawdzamy jego ustawienia (uwaga licencja musi być wyższa niż Exchange Kiosk!)
Same ustawienia są jak widać poprawne, pewnie jeszcze poeksperymentujecie z checkiem: „SMTP z uwierzytelnianiem” ale niestety to tez nie przyniesie efektu.
Dalej pozostaje dokumentacja technetu na temat uruchomienia SMTP bez autentykacji użytkownika i wysyłka z określonych adresów IP (np przez stare urządzenia wielofunkcyjne). W skrócie tworzymy odpowiedni konektor ze wskazaniem na zewnętrzny adres IP, dodajemy wpis do rekordu SFP, w ustawieniach używamy adresu serwera SMTP z nazwa tenant id (np sprawdzone-it.onmicrosoft.com) ale to jednak mało bezpieczne rozwiązanie, każdy w „zasięgu” tego samego IP może wysłać w imieniu każdego.
Gdzie zatem leży problem? Przecież innym to działa? W sieci jest pełno tematów z tym związanych, ale żadnego konkretnego rozwiązania. Niektórzy wspominają że po zgłoszeniu na suport Microsoft problem nagle znika, inni mówią ze należy poczekać, lub zmieniać hasła na proste! Filtrując daty wpisów zauważamy, że ich nasilenie pojawia się w kwietniu 2020 roku, Microsoft zmienia konfiguracje domyślna swojej usługi z okazji rebrandingu Office 365 na Microsoft 365. Tak to o to chodzi!
Zmieniona konfiguracja to jeden z atrybutów konfiguracji, dla nowych klientów ustawiają na całej usłudze:
SmtpClientAuthenticationDisabled: TrueAby zmienić ten parametr musimy połączyć się znasza usługą jako jej administrator z poziomu PowerShell’a, w tym celu użyjmy ogolono dostępnego skryptu:
$UserCredential = Get-Credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic -AllowRedirection
Import-PSSession $Session -DisableNameCheckingNastępnie weryfikujemy obecne ustawienia naszego konta Microsoft 365 / Office 365:
Get-TransportConfigW wyniku powyższego polecenia otrzymujemy pełną konfiguracje:
ddressBookPolicyRoutingEnabled : False
AnonymousSenderToRecipientRatePerHour : 1800
ClearCategories : True
ConvertDisclaimerWrapperToEml : False
DSNConversionMode : PreserveDSNBody
JournalArchivingEnabled : False
ExternalDelayDsnEnabled : True
ExternalDsnDefaultLanguage :
ExternalDsnLanguageDetectionEnabled : True
ExternalDsnMaxMessageAttachSize : 10 MB (10,485,760 bytes)
ExternalDsnReportingAuthority :
ExternalDsnSendHtml : True
ExternalPostmasterAddress :
GenerateCopyOfDSNFor : {}
HygieneSuite : Premium
InternalDelayDsnEnabled : True
InternalDsnDefaultLanguage :
InternalDsnLanguageDetectionEnabled : True
InternalDsnMaxMessageAttachSize : 10 MB (10,485,760 bytes)
InternalDsnReportingAuthority :
InternalDsnSendHtml : True
InternalSMTPServers : {}
JournalingReportNdrTo : <>
LegacyJournalingMigrationEnabled : False
LegacyArchiveJournalingEnabled : False
LegacyArchiveLiveJournalingEnabled : False
RedirectUnprovisionedUserMessagesForLegacyArchiveJournaling : False
RedirectDLMessagesForLegacyArchiveJournaling : False
MaxDumpsterSizePerDatabase : 18 MB (18,874,368 bytes)
MaxDumpsterTime : 7.00:00:00
MaxReceiveSize : Unlimited
MaxRecipientEnvelopeLimit : Unlimited
MaxSendSize : Unlimited
MigrationEnabled : True
OpenDomainRoutingEnabled : False
Rfc2231EncodingEnabled : False
SafetyNetHoldTime : 7.00:00:00
SmtpClientAuthenticationDisabled : True
SupervisionTags : {Reject, Allow}
TLSReceiveDomainSecureList : {}
TLSSendDomainSecureList : {}
VerifySecureSubmitEnabled : False
VoicemailJournalingEnabled : True
HeaderPromotionModeSetting : NoCreate
Xexch50Enabled : TrueNie zamykając okna terminala zmieniamy wartość parametru na False:
Set-TransportConfig -SmtpClientAuthenticationDisabled $falseTeraz wystarczy już tylko sprawdzić czy wprowadzona zmiana przyniosła efekt!