Jak szeroko obsługiwane jest wymuszone TLS na przychodzących połączeniach SMTP?


10

Prowadzę MTA składający się ze standardowych czeków Postfix, SpamAssassin, ClamAV, SPF / DKIM itp. To MTA jest używane tylko do przychodzących wiadomości e-mail, nie obsługuje żadnych kont i przekazuje pocztę, która przekazuje wspomniane czeki do udostępnionego hosta internetowego.

Wiem, że niektóre usługi e-mail zaczynają próbować połączeń TLS przed zwykłym tekstem podczas próby dostarczenia poczty na mój serwer.

Zdaję sobie sprawę, że nie wszystkie usługi będą obsługiwać TLS, ale zastanawiam się, jak dobrze jest przystosowany, aby móc zaspokoić bezpieczeństwo mózgu OCD (tak, wiem, że SSL nie jest tak bezpieczny, jak kiedyś sądziliśmy, że był ...)

Dokumentacja Postfix dla smtpd_tls_security_levelstanów stwierdza, że RFC 2487 stanowi, że wszystkie publiczne serwery pocztowe (tj. MX) nie wymuszają TLS:

Zgodnie z RFC 2487 NIE WOLNO go stosować w przypadku publicznego serwera SMTP. Ta opcja jest zatem domyślnie wyłączona.

A zatem: na ile odpowiednia / istotna jest dokumentacja (lub 15-letni RFC w tej kwestii) i czy mogę bezpiecznie wymusić TLS na wszystkich przychodzących połączeniach SMTP bez blokowania połowy światowych dostawców usług internetowych?


1
Standardy są tworzone przez komitety, których członkowie prawdopodobnie nigdy nie pracowali jako sysadmin nawet przez jeden rok w życiu, i jest to dość widoczne w praktycznie każdej specyfikacji standardu internetowego. W przypadku RFC sytuacja jest nieco lepsza, ale RFC nie są standardami. Są to warcaby („ r r estre f lub c omments”). I: otrzymujesz wynagrodzenie nie z papieru, ale z firmy.
Peter - Przywróć Monikę

7
To RFC zostało zdezaktualizowane przez RFC 3207 . Jego autor jest już o wiele dłużej, niż wydaje się sądzić jeden komentator.
Michael Hampton,

6
W przypadku wychodzących wiadomości e-mail, oto statystyki z Facebooka: Obecny stan wdrożenia SMTP STARTTLS
masegaloeh

Niepewny powód pojedynczego głosowania. Dziękuję Michel i Peter za twoje opinie, bardzo mile widziane.
Craig Watson

Odpowiedzi:


7

To bardzo skomplikowane pytanie, biorąc pod uwagę, że dostawcy poczty na całym świecie nie dostarczają łatwo statystyk dotyczących swoich serwerów pocztowych.

Samodiagnoza

Aby ustalić odpowiedź na pytanie na podstawie własnego serwera / równorzędnych domen, możesz włączyć rejestrowanie SSL:

postconf -e \
    smtpd_tls_loglevel = "1" \
    smtpd_tls_security_level = "may"

postconf
postfix reload

Zakłada się, że przez pewien czas zapisujesz wiadomości syslog poczty. Jeśli nie, być może skonfiguruj strategię archiwizacji syslog i napisz skrypt powłoki, aby podsumować użycie TLS na twoim serwerze. Być może istnieją już skrypty do tego.

Gdy poczujesz się komfortowo, gdy wszyscy Twoi rówieśnicy obsługują TLS oraz siłę szyfru i protokołu, którą chcesz egzekwować, możesz podjąć świadomą decyzję. Każde środowisko jest inne. Nie ma jednej odpowiedzi, która zaspokoi Twoje potrzeby.

Moje osobiste doświadczenie

Za to, co jest warte, mój osobisty serwer pocztowy wymusza TLS. Ma to zabawny efekt uboczny negowania większości botów spamowych, ponieważ większość z nich nie obsługuje TLS. (Do tej pory polegałem na metodologii regexp S25R)

Aktualizacja

Minął rok, odkąd odpowiedziałem na to pytanie, a jedynymi problemami, jakie otrzymałem z powodu wymuszonego włączenia wiadomości e-mail z TLS, były serwery front-end w Blizzard (kontrola rodzicielska) i system zarządzania Linode. Wygląda na to, że wszyscy, z którymi współpracuję, wspierają TLS przy użyciu silnych szyfrów.

Środowisko korporacyjne

W środowisku korporacyjnym gorąco zachęcam do włączenia rejestrowania TLS i pozostawienia go uruchomionego przez dość długi czas przed wymuszeniem TLS. Zawsze możesz wymusić TLS dla określonych nazw domen w pliku tls_policy.

postconf -d smtp_tls_policy_maps

Witryna z postfiksami zawiera świetną dokumentację dotyczącą korzystania z map zasad tls. Możesz przynajmniej zapewnić, że określone domeny, które dostarczają poufnych informacji, są szyfrowane, nawet jeśli ISP próbuje usunąć obsługę TLS w początkowym połączeniu z serwerem.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.