Perché SMTP su SSL tra server di posta elettronica non è così popolare? [chiuso]

A mio avviso, la maggior parte dei server di posta elettronica utilizza SMTP / POP / IMAP su SSL per crittografare l'e-mail.
Supporta la crittografia quando client (UA) invia e-mail al server (MTA) e UA riceve e-mail da MTA. Tuttavia, non molti MTA possono crittografare quando inviano e-mail tra MTA e MTA.
(la mia comprensione è corretta?)

ad es. alice@somewhere.com invia e-mail a bob@anywhere.org
[PC di Alice] --- crittografato (SMTPS) ---> [server somewhere.com] --- NON ENCRYPTED (SMTP) ---> [ovunque. org server] --- crittografato (POPS o IMAPS) ---> [Bob's PC]

Se la mia comprensione è corretta, perché la maggior parte dei server di posta elettronica non supporta SMTP su SSL tra server di posta elettronica?

Sviluppo un'interfaccia migliore (meno complessa) per abilitare la crittografia e-mail con PGP / GPG, ma in questi giorni penso che potrebbe essere meglio usare SMTPS perché PGP / GPG ha bisogno della firma manuale delle chiavi per mantenere l'affidabilità.

— Jumpei Ogawa
fonte

Cosa c'entra questo con la crittografia e-mail? crittografia e-mail significa per me che l'email è crittografata da sola ...

— Uwe Plonus

?? Spiacenti, non ho capito cosa intendi ... Come "l'e-mail è crittografata da sola"? A mio avviso, l'e-mail può essere facilmente intercettata se si invia e-mail come testo normale (senza crittografia).

— Jumpei Ogawa,

Sì, ma l'invio di un'e-mail crittografata non ha nulla a che fare con la crittografia SSL / TLS del server SMTP.

— Uwe Plonus,

Per assicurarti di ricevere posta solo su un canale crittografato sul tuo server SMTP, dovrai forzare l' utilizzo di TLS. Pertanto, se l'altra parte non comprende / supporta TLS, non riceverai la tua posta. Se si consente un fallback alla comunicazione non crittografata, non si ottiene nulla. Questo è il motivo per cui le persone preferiscono piuttosto crittografare la posta stessa e inviarla su un canale non crittografato.

— Der Hochstapler,

Per chiarire: "e-mail crittografata" si riferisce alla crittografia dei contenuti utilizzando qualcosa come PGP prima ancora di inviarli al server di posta in uscita. Ciò ha l'ulteriore vantaggio di tenerlo segreto per chiunque gestisca il tuo MTA. Non si riferisce alla crittografia dell'email tra MTA; la crittografia viene normalmente applicata solo alle estremità, non al centro. Si noti inoltre che la comunicazione tra UA e MTA comporta spesso la trasmissione di una qualche forma di password, che dovrebbe essere comunque crittografata.

— 1313

Bella domanda, non ho davvero visto cifre per questo. Non sono sicuro, ma penso che molte grandi aziende ora supportino SSL / TLS per SMTP in entrata e in uscita (consegna di posta "MX"). Questo è normalmente facoltativo e può essere negoziato tramite StartTLS sulla porta 25. La maggior parte dei server SMTP non richiede TLS da server a server, tuttavia, poiché ciò significherebbe che molti non sarebbero in grado di ricevere posta da un MTA che non supporta o non è configurato per TLS.

Molti client di posta elettronica supportano TLS tra UA e MTA: SMTP / IMAP su SSL o POP3 su SSL. Penso che gmail, ad esempio, richieda SSL / TLS per IMAP e POP3.

Per quanto riguarda la crittografia e-mail effettiva end-to-end, ciò viene normalmente ottenuto utilizzando S / MIME o PGP. Tuttavia, a causa della complessità nella creazione e gestione, non ha visto l'adozione su larga scala.

— woollybrain
fonte

Grazie. Quindi la mia comprensione dello stato attuale della crittografia e-mail. Vuoi dire che SMTPS da server a server non è supportato in molti server perché il software server come Postfix non lo supporta? Se la maggior parte dei server di posta lo supporta, il problema sarà risolto? (Forse non capisco la tua risposta correttamente ...)

— Jumpei Ogawa,

Anche quando viene negoziata la crittografia, di solito non viene eseguito un controllo rigoroso dei certificati perché ciò bloccherebbe tutti quei server con certificati autofirmati. Ma senza un controllo rigoroso un attacco man-in-the-middle è facile (per non parlare del fatto che un MITM potrebbe prevenire STARTTLS intervenendo nella fase in chiaro)

— Hagen von Eitzen,

RFC 2487 vieta ai server di posta pubblici di richiedere TLS: "Un server SMTP a riferimento pubblico NON DEVE richiedere l'uso dell'estensione STARTTLS per recapitare la posta localmente. Questa regola impedisce all'estensione STARTTLS di danneggiare l'interoperabilità dell'infrastruttura SMTP di Internet".

— ARX,