Czy nadal „niewłaściwe” jest wymaganie STARTTLS na przychodzących wiadomościach SMTP

15

Zgodnie z sekcją 5 specyfikacji STARTTLS :

Publicznie wskazany serwer SMTP NIE MOŻE wymagać użycia
rozszerzenia STARTTLS w celu dostarczania poczty lokalnie. Ta reguła
zapobiega uszkodzeniu przez rozszerzenie STARTTLS interoperacyjności internetowej infrastruktury SMTP. Publicznie wymieniony serwer SMTP to serwer SMTP, który działa na porcie 25 hosta internetowego wymienionego w rekordzie MX (lub rekordzie A, jeśli rekord MX nie jest obecny) dla
nazwy domeny po prawej stronie adresu poczty internetowej .

Jednak ta specyfikacja została napisana w 1999 roku i biorąc pod uwagę 2014 rok, oczekiwałbym, że większość klientów, serwerów i przekaźników SMTP będzie miała jakąś implementację STARTTLS.

Ile wiadomości e-mail mogę utracić, jeśli wymagam STARTTLS do wiadomości przychodzących?

email  smtp  starttls 
— jackweirdy
źródło
1
Dobre pytanie. Wymuszenie włączenia TLS nie zapobiegnie SPAM.
— Matt
1
Nie spodziewam się tego, po prostu chcę szyfrowania (które wydaje się, że otrzymuję od 90% przychodzących wiadomości, nie wymagając tego) :)
— jackweirdy
2
@Matt Sprawdziłem ostatnio otrzymane maile na jednym serwerze pocztowym i znalazłem to. Z wiadomości otrzymanych za pomocą TLS było 4% spamu, z wiadomości otrzymanych bez TLS było 100% spamu. Nie blokowałbym całkowicie wiadomości e-mail bez TLS opartych na tym, ale z pewnością jest to silny sygnał, który można wykorzystać w filtrowaniu spamu.
— kasperd
@kasperd - możesz włączyć TLS lub użyć go jako środka do redukcji spamu, ale to nie potrwa długo. To tak naprawdę znaczy, że klient smtp, którego używają do przesyłania spamu na twój serwer, nie używa TLS, lub może próbuje nie używać TLS domyślnie, ale może spróbować sesji obsługującej TLS, jeśli jest to wymagane. W najlepszym razie zobaczysz chwilowe zmniejszenie SPAMU, ale spodziewam się, że z czasem wróci do normalnego poziomu.
— Matt
@Matt Dotyczy to większości obecnie stosowanych metod zwalczania spamu. Innym problemem związanym z większością podejść jest to, że blokują one zbyt wiele wiarygodnych wiadomości e-mail. Ludzie rzadko zastanawiają się, ile prawidłowych wiadomości e-mail można zablokować.
— kasperd

Odpowiedzi:

19

Tak, to wciąż zły pomysł.

Trzy powody:

  1. Podczas gdy cytowany RFC ( RFC 2487 ) jest w rzeczywistości nieaktualny w obecnym standardzie RFC 3207 , obecny standard MUSI NIE MIEĆ verbage, który zacytowałeś w swoim pytaniu.

  2. Klienci SMTP nie są zobowiązani do wdrożenia STARTTLS. Całkowicie nie można tego robić. Chociaż STARTTLS staje się coraz bardziej powszechny, absolutnie nie jest uniwersalny.

  3. Z powodów 1 i 2, jeśli potrzebujesz STARTTLS na wszystkich połączeniach przychodzących, utracisz pocztę.

Jednak:

Twój serwer - twoje zasady. Jeśli chcesz dowolnie odrzucić dowolną pocztę z dowolnego powodu, a nawet bez powodu - to twoje prawo i przywilej. (nie oznacza to, że jest zawsze świetny pomysł, jednak)

Notatki dodatkowe:

Nie zapobiegniesz spamowi, wymagając STARTTLS, nawet jeśli potrzebujesz wzajemnego uwierzytelnienia STARTTLS. Spamerzy również mogą uzyskiwać certyfikaty lub tworzyć samopodpisane. Odrzucenie samopodpisanych certyfikatów klienta spowoduje również utratę legalnej poczty.

STARTTLS to szyfrowanie punkt-punkt. System łączenia nadal może odczytać treść wiadomości e-mail. Jeśli chcesz prawdziwej prywatności, potrzebujesz czegoś kompleksowego, takiego jak OpenPGP lub S / MIME.

To powiedziawszy, STARTTLS usuwa jedną możliwą ścieżkę przechwytywania lub MITM, a zatem nadal dobrym pomysłem jest używanie go, gdy jest to wykonalne, tj. Gdy druga strona też go popiera.

— Joe Sniderman
źródło
1
Uwaga dotycząca certyfikatów i spamu jest nie na miejscu. To odbiorca potrzebuje certyfikatu, a nie nadawca.
— kasperd
nie pomoże zapobiec spamowi. Nawet jeśli wprowadzisz obowiązek wzajemnego uwierzytelniania STARTTLS. Zaktualizuje odpowiedź, aby wyjaśnić.
— Joe Sniderman
2
+1 na notatce o spamie. Tylko dlatego, że jest zaszyfrowany, nie zapewnia bezpieczeństwa.
— Matt
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.