Postfix smtps i zamieszanie podczas przesyłania

Skonfigurowałem Postfiks, aby klienci e-mail używali portu 465 (smtps) dla poczty wychodzącej. Naprawdę nie rozumiem różnicy między smtps (port 465) a przesyłaniem (port 587)

Jaka jest „najlepsza praktyka” podczas konfigurowania Postfiksa dla klientów, aby bezpiecznie wysyłać pocztę? Używasz tylko smtps? Lub użyj zarówno przesyłania, jak i smtps?

Port 465 był używany do połączeń SMTP zabezpieczonych przez SSL. Jednak korzystanie z tego portu do SMTP stało się przestarzałe z powodu dostępności STARTTLS: „Odwoływanie portu TCP smtps” Obecnie nie powinieneś już używać Portu 465 dla SMTPS. Zamiast tego użyj portu 25 do odbierania wiadomości e-mail dla Twojej domeny z innych serwerów lub portu 587 do odbierania wiadomości e-mail od klientów, którzy muszą wysyłać wiadomości e-mail przez serwer do innych domen, a tym samym do innych serwerów.

Jako dodatkową uwagę port 587 jest jednak dedykowany do wysyłania poczty - a przesyłanie poczty ma na celu zmianę wiadomości i / lub zapewnienie uwierzytelnienia:

• oferowanie i wymaganie uwierzytelnienia dla klientów, którzy próbują przesyłać wiadomości e-mail
• udostępnianie mechanizmów bezpieczeństwa zapobiegających przesyłaniu niechcianej poczty masowej (spamu) lub zainfekowanych wiadomości e-mail (wirusów itp.)
• zmodyfikuj pocztę do potrzeb organizacji (przepisywanie części, itp.)

Przesyłanie na port 587 ma obsługiwać STARTTLS, a zatem może być szyfrowane. Zobacz także RFC # 6409 .

TL; DR

Nowe zalecenie ma na razie wspierać zarówno przesyłanie / smtps, jak i przesyłanie za pomocą STARTTLS, a wycofywanie później, gdy już nie będzie używane. (Te same zalecenia dotyczą również POP3 vs POP3S i IMAP vs IMAPS.)

Detale

Najlepsza praktyka uległa zmianie w RFC 8314 sekcja 3.3 :

Po ustanowieniu połączenia TCP dla usługi „wysyłania” (domyślny port 465) natychmiast rozpoczyna się uzgadnianie TLS. […]

Mechanizm STARTTLS na porcie 587 jest stosunkowo szeroko rozpowszechniony ze względu na sytuację z portem 465 (omówioną w rozdziale 7.3). Różni się to od usług IMAP i POP, w których Implicit TLS jest częściej wdrażany na serwerach niż STARTTLS. Pożądane jest, aby migrować podstawowych protokołów wykorzystywanych przez oprogramowanie MUA do dorozumiane TLS w czasie, w celu zachowania spójności, jak również dla dodatkowych powodów omówionych w Dodatku A . Jednak, aby zmaksymalizować wykorzystanie szyfrowania do przesyłania, pożądane jest wspieranie obu mechanizmów przesyłania wiadomości przez TLS na okres przejściowy kilku lat. W rezultacie klienci i serwery MUSZĄ wdrożyć zarówno STARTTLS na porcie 587, jak i niejawne TLS na porcie 465 w tym okresie przejściowym. Należy zauważyć, że nie ma znaczącej różnicy między właściwościami zabezpieczeń STARTTLS na porcie 587 i niejawnym TLS na porcie 465, jeśli implementacje są poprawne i jeśli zarówno klient, jak i serwer są skonfigurowane tak, aby wymagały pomyślnej negocjacji TLS przed wysłaniem wiadomości.

Przytoczony załącznik A omawia następnie decyzję o preferowaniu niejawnego TLS dla wszystkich SMTP, POP3 i IMAP, ponieważ te główne punkty

1. Chcemy tylko połączeń szyfrowanych nie wszędzie tak czy inaczej, więc nie ma sensu utrzymywanie wstecznie zgodny wersję tych wszystkich protokołów, gdy w praktyce, że Kompatybilność nie jest używany
2. Wystąpiły exploity z fazy negocjacji STARTTLS z powodu identycznych problemów w kilku implementacjach