È ancora "sbagliato" richiedere STARTTLS sui messaggi SMTP in arrivo

15

Secondo la Sezione 5 delle specifiche STARTTLS :

Un server SMTP referenziato pubblicamente NON DEVE richiedere l'uso
dell'estensione STARTTLS per consegnare la posta localmente. Questa regola
impedisce all'estensione STARTTLS di danneggiare l'interoperabilità dell'infrastruttura SMTP di Internet. Un server SMTP a riferimento pubblico è un server SMTP che viene eseguito sulla porta 25 di un host Internet elencato nel record MX (o un record se non è presente un record MX) per il
nome di dominio sul lato destro di un indirizzo di posta Internet .

Tuttavia, questa specifica è stata scritta nel 1999 e, considerato che è il 2014, mi aspetto che la maggior parte dei client, dei server e dei relè SMTP abbia una sorta di implementazione di STARTTLS.

Quante email posso aspettarmi di perdere se richiedo STARTTLS per i messaggi in arrivo?

email  smtp  starttls 
— jackweirdy
fonte
1
Buona domanda. Avere TLS forzato non impedisce lo SPAM.
— Matt,
1
Non me lo aspetto, voglio solo la crittografia (che sembra ottenere dal 90% dei messaggi in arrivo senza averlo richiesto) :)
— jackweirdy,
2
@Matt Ho controllato le mail ricevute di recente su un particolare server di posta e l'ho trovato. Delle mail ricevute con TLS c'era il 4% di spam, delle mail ricevute senza TLS c'era il 100% di spam. Basandomi su questo non bloccherei completamente la posta senza TLS, ma è certamente un segnale forte, che potrebbe essere utilizzato nel filtro antispam.
— Kasperd,
@kasperd: potresti attivare TLS o utilizzarlo come mezzo per ridurre lo spam, ma non durerà. Significa davvero che il client smtp che stanno usando per inviare spam al tuo server non sta usando TLS, o forse cerca di non usare TLS per impostazione predefinita, ma può provare una sessione abilitata TLS se è richiesta. Nel migliore dei casi, vedrai una riduzione temporanea dello SPAM, ma mi aspetto che ritorni ai livelli normali nel tempo.
— Matt,
@Matt Questo vale per la maggior parte degli approcci attualmente adottati contro lo spam. Un altro problema con la maggior parte degli approcci è che bloccano troppe e-mail legittime. Le persone raramente considerano quante email legittime è accettabile bloccare.
— Kasperd,

Risposte:

19

Sì, è ancora una cattiva idea.

Tre motivi:

  1. Mentre l'RFC che hai citato ( RFC 2487 ) è in effetti obsoleto dall'attuale standard RFC 3207 , lo standard attuale mantiene la DEVE NON verbosità citata nella tua domanda.

  2. I client SMTP non sono tenuti ad implementare STARTTLS. È assolutamente accettabile non farlo. Mentre STARTTLS sta diventando più comune, non è assolutamente universale.

  3. A causa dei motivi 1 e 2, se si richiede STARTTLS su tutte le connessioni in entrata, si perde la posta.

Tuttavia:

Il tuo server - le tue regole. Se si desidera rifiutare arbitrariamente qualsiasi posta per qualsiasi motivo, o anche senza motivo, questo è il tuo diritto e privilegio. (non significa che sia necessariamente un'ottima idea comunque)

Note a margine:

Non previeni lo spam richiedendo STARTTLS, anche se richiedi l'autenticazione STARTTLS reciproca. Anche gli spammer possono ottenere certificati o crearne di nuovi autofirmati. Il rifiuto di certificati client autofirmati comporta anche la perdita di posta legittima.

STARTTLS è la crittografia punto a punto. Il sistema di connessione può ancora leggere il contenuto dell'e-mail. Se vuoi una vera privacy, hai bisogno di qualcosa end-to-end, come OpenPGP o S / MIME.

Detto questo, STARTTLS rimuove una possibile strada per l'intercettazione o MITM e quindi è comunque una buona idea usarlo quando possibile, cioè quando anche l'altra parte lo supporta.

— Joe Sniderman
fonte
1
La nota su certificati e spam è fuori posto. È il destinatario che ha bisogno di un certificato, non del mittente.
— Kasperd,
non aiuterà a prevenire lo spam. Anche se rendi obbligatoria l'autenticazione reciproca per STARTTLS. Aggiornerà la risposta per chiarire.
— Joe Sniderman,
2
+1 sulla nota relativa allo spam. Solo perché è crittografato non lo rende sicuro.
— Matt,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.