Send-MailMessage nie działa – brak TLS

Send-MailMessage niedziałające (brak TLS) wskazuje na przestarzały cmdlet PowerShell niewspierający nowoczesnego szyfrowania wymaganego przez współczesne serwery pocztowe.

Send-MailMessage nie działa – brak TLS: co oznacza ten problem

Komunikat lub zachowanie wskazujące, że Send-MailMessage nie nawiązuje połączenia z wymaganym szyfrowaniem TLS, zwykle oznacza niezgodność między starszym sposobem wysyłania poczty w PowerShellu a aktualnymi zasadami bezpieczeństwa serwera SMTP. Sam cmdlet może poprawnie przyjąć parametry, rozpocząć próbę połączenia i dopiero wtedy zakończyć działanie błędem związanym z negocjacją protokołu, certyfikatem albo uwierzytelnianiem. Nie musi to oznaczać uszkodzenia systemu Windows ani nieprawidłowego działania całego konta pocztowego.

Send-MailMessage jest rozwiązaniem wycofywanym i nie powinno być traktowane jako uniwersalne narzędzie do współczesnej automatyzacji poczty. W praktyce problem pojawia się wtedy, gdy serwer wymaga bezpiecznego połączenia, określonej wersji TLS, poprawnej walidacji certyfikatu lub nowoczesnego mechanizmu logowania, a używany cmdlet nie potrafi prawidłowo obsłużyć tych wymagań. Szyfrowanie TLS chroni transmisję między skryptem a serwerem pocztowym, lecz jego zastosowanie wymaga zgodności po obu stronach: w systemie, bibliotekach kryptograficznych, konfiguracji PowerShella i ustawieniach usługi SMTP.

Warto odróżnić brak TLS od zwykłego błędu hasła. Przy odrzuconym haśle serwer często pozwala najpierw utworzyć połączenie, a dopiero później odmawia autoryzacji. Przy problemie z TLS sesja może zostać przerwana już podczas uzgadniania bezpiecznego kanału. W rezultacie w logach lub konsoli mogą pojawić się informacje o zamknięciu połączenia, niezgodnej wersji protokołu, nieprawidłowym certyfikacie, braku zaufania do wystawcy albo odrzuceniu starego sposobu szyfrowania.

Jak TLS wpływa na wysyłanie poczty z PowerShella

Wysyłka wiadomości przez SMTP składa się z kilku etapów. Najpierw następuje połączenie z właściwym hostem i portem, później serwer przedstawia swoją ofertę, a klient uzgadnia sposób zabezpieczenia transmisji. W zależności od konfiguracji może być użyte bezpośrednie szyfrowanie od początku sesji albo przejście z połączenia początkowo nieszyfrowanego do kanału chronionego po komendzie STARTTLS. Dopiero po udanym etapie TLS powinno dojść do uwierzytelnienia i przekazania wiadomości.

W tym łańcuchu znaczenie mają między innymi: nazwa hosta SMTP, używany port, sposób uruchamiania TLS, nazwa nadawcy, metoda uwierzytelniania oraz zaufanie do certyfikatu. Pomylenie trybu szyfrowania z numerem portu może powodować błąd, mimo że adres serwera jest prawidłowy. Podobny skutek występuje, gdy certyfikat został wystawiony dla innej nazwy hosta, łańcuch certyfikatów nie jest dostępny w systemie albo zegar urządzenia wskazuje niewłaściwą datę.

Istotna jest także wersja środowiska uruchomieniowego. Starszy Windows PowerShell może korzystać z ustawień i składników systemowych, które nie odpowiadają obecnej polityce bezpieczeństwa serwera. Wymuszenie nowszego protokołu może czasem usunąć jeden objaw, ale nie zawsze rozwiązuje całość, ponieważ nadal może występować problem z certyfikatem, metodą logowania albo samą konstrukcją cmdletu. Z tego powodu samo dopisanie pojedynczej opcji do skryptu nie powinno być uznawane za pełną naprawę.

W nowych wdrożeniach częściej wybiera się bibliotekę lub moduł obsługujący aktualne mechanizmy SMTP, bezpieczne przechowywanie poświadczeń i współczesne metody autoryzacji. Przy większej liczbie automatycznych wysyłek można również rozważyć usługę pośredniczącą albo interfejs API dostawcy poczty, jeżeli dana usługa go udostępnia. Rozwiązanie powinno być dobrane do rodzaju konta, wymagań administratora oraz sposobu przechowywania danych dostępowych.

Typowe przyczyny błędu braku TLS

Jednym z częstych powodów jest użycie niewłaściwego portu lub trybu szyfrowania. Serwer oczekujący określonego sposobu rozpoczęcia sesji może odrzucić klienta, który próbuje zastosować inny wariant. Nie należy też zakładać, że każdy serwer SMTP działa według identycznych zasad. Konfiguracja poczty firmowej, dostawcy internetowego i zewnętrznej platformy transakcyjnej może różnić się wymaganiami dotyczącymi szyfrowania, przekazywania wiadomości oraz uwierzytelniania.

Drugą grupę przyczyn stanowią ograniczenia środowiska. Nieaktualne składniki systemu, wyłączone biblioteki kryptograficzne, brak aktualnych certyfikatów głównych lub zasady bezpieczeństwa narzucone przez administratora mogą zmieniać sposób obsługi TLS. Warto sprawdzić, czy problem występuje tylko w jednym skrypcie, czy również w innych narzędziach korzystających z tego samego połączenia. Jeżeli inne aplikacje także nie mogą utworzyć bezpiecznej sesji, przyczyna może znajdować się niżej, na poziomie systemu, zapory sieciowej, inspekcji ruchu lub urządzenia pośredniczącego.

Osobny problem może dotyczyć certyfikatu. Certyfikat serwera powinien być aktualny, zgodny z nazwą używanego hosta i możliwy do zweryfikowania przez system. Błąd może pojawić się po zmianie dostawcy poczty, migracji skrzynki, odnowieniu certyfikatu lub zmianie nazwy punktu SMTP. Nie powinno się omijać walidacji certyfikatu przez wyłączanie kontroli bezpieczeństwa, ponieważ pozornie skuteczna wysyłka może wtedy odbywać się bez prawidłowej ochrony przed podszyciem się pod serwer.

W niektórych usługach problem wywołuje także wycofanie prostego logowania hasłem. Konto może wymagać hasła aplikacji, zgody administratora, uwierzytelniania wieloetapowego albo tokenu. W takiej sytuacji poprawny TLS nie wystarczy, ale komunikat zwracany przez starszy cmdlet może być mało precyzyjny i sugerować wyłącznie problem z szyfrowaniem. Analiza powinna dlatego obejmować zarówno etap tworzenia kanału TLS, jak i późniejszą odpowiedź serwera na próbę logowania.

Przydatne jest zebranie pełnego komunikatu, informacji o wersji Windows i PowerShella, nazwie używanego hosta SMTP oraz momencie, w którym sesja zostaje przerwana. Należy unikać publikowania haseł, tokenów i pełnych nagłówków zawierających dane wrażliwe. W przypadku automatyzacji warto dodatkowo sprawdzić, czy skrypt nie przechowuje poświadczeń w zwykłym tekście oraz czy po zmianie konfiguracji nie pozostawiono starego hasła lub nieaktualnego adresu serwera.

Kiedy warto oddać urządzenie do diagnozy - Send-MailMessage nie działa – brak TLS

Pomoc techniczna jest wskazana, gdy wysyłanie poczty przestało działać po aktualizacji systemu, zmianie dostawcy skrzynki, wdrożeniu nowych zasad bezpieczeństwa albo migracji skryptów na inne stanowisko. Warto zgłosić problem również wtedy, gdy wiadomości wychodzą z programu pocztowego, lecz nie są wysyłane z PowerShella, albo gdy błąd pojawia się tylko na jednym komputerze. Takie porównanie pozwala rozdzielić problem konta od problemu konkretnego środowiska.

Przed przekazaniem urządzenia dobrze przygotować treść komunikatu błędu, opis oczekiwanego działania, informację o tym, czy awaria dotyczy wszystkich odbiorców, oraz bezpiecznie zanonimizowany fragment skryptu. Przydatne może być wskazanie, czy korzystano z STARTTLS, czy połączenie miało być szyfrowane od początku oraz czy ostatnio zmieniano hasło lub ustawienia serwera. Nie powinno się przesyłać w wiadomości jawnych poświadczeń ani wpisywać ich do skryptu podczas testów bez odpowiedniego zabezpieczenia.

W Warszawskim Pogotowiu Komputerowym 24/7 dostępna jest darmowa diagnoza LAPTOPA, podczas której można sprawdzić konfigurację PowerShella, składniki odpowiedzialne za TLS, certyfikaty, połączenie sieciowe i sposób uwierzytelniania. Po ustaleniu źródła problemu można dobrać bezpieczniejszy sposób wysyłania wiadomości, uporządkować ustawienia systemowe albo przygotować skrypt do pracy z rozwiązaniem zgodnym z aktualnymi wymaganiami serwera pocztowego.