Postfix smtps e confusione di presentazione


13

Ho installato postfix in modo che i client di posta elettronica utilizzino la porta 465 (smtps) per la posta in uscita. Non capisco davvero la differenza tra smtps (porta 465) e invio (porta 587)

Qual è la "best practice" quando si configura Postfix per i client per l'invio sicuro di posta? Basta usare smtps? O utilizzare sia l'invio che smtps?

Risposte:


21

La porta 465 è stata utilizzata per le connessioni SMTP protette da SSL. Tuttavia, l'utilizzo di quella porta per SMTP è stato deprecato con la disponibilità di STARTTLS: "Revoca della porta TCP smtps" Al giorno d'oggi non è più necessario utilizzare la porta 465 per SMTPS. Utilizzare invece la porta 25 per ricevere e-mail per il proprio dominio da altri server o la porta 587 per ricevere e-mail da client, che devono inviare e-mail attraverso il proprio server ad altri domini e quindi ad altri server.

Come nota aggiuntiva, la porta 587 è tuttavia dedicata all'invio di posta - e l'invio di posta è progettato per modificare il messaggio e / o fornire l'autenticazione:

  • offrire e richiedere l'autenticazione per i clienti che provano a inviare posta
  • fornire meccanismi di sicurezza per impedire l'invio di posta indesiderata (spam) o posta infetta (virus, ecc.)
  • modificare la posta in base alle esigenze di un'organizzazione (riscrivendo la parte da, ecc.)

L'invio alla porta 587 dovrebbe supportare STARTTLS e quindi può essere crittografato. Vedi anche RFC # 6409 .


Grazie per la risposta, ho impostato correttamente l'invio con Postfix e le cose sono molto più chiare per me ora. :-)
Aditya K,

Prego =)
liquidat

1
Il traffico sulla porta 465 è completamente crittografato. Quando si utilizza starttls, il client può accedere alla trasmissione protetta ed uscire da esso inviando i dati senza crittografia. serverfault.com/q/523804/201912
QkiZ

2

TL; DR

La nuova raccomandazione è quella di supportare sia di presentazioni / SMTPS e presentazione con STARTTLS per il momento, la graduale eliminazione in seguito una volta che non è più utilizzato. (Le stesse raccomandazioni valgono anche per POP3 vs POP3S e IMAP vs IMAPS.)

Dettagli

La migliore pratica è cambiata con RFC 8314 Sezione 3.3 :

Quando viene stabilita una connessione TCP per il servizio "invii" (porta predefinita 465), inizia immediatamente un handshake TLS. [...]

Il meccanismo STARTTLS sulla porta 587 è relativamente diffuso a causa della situazione con la porta 465 (discussa nella Sezione 7.3). Ciò differisce dai servizi IMAP e POP in cui il TLS implicito è distribuito più ampiamente sui server rispetto a STARTTLS. È auspicabile protocolli di base Migrazione utilizzati dal software MUA TLS impliciti nel tempo, per consistenza e per i motivi aggiuntivi illustrati in Appendice A . Tuttavia, per massimizzare l'uso della crittografia per l'invio, è auspicabile supportare entrambi i meccanismi per l'invio di messaggi su TLS per un periodo di transizione di diversi anni. Di conseguenza, i client e i server DOVREBBERO implementare sia STARTTLS sulla porta 587 che TLS implicito sulla porta 465 per questo periodo di transizione. Si noti che non vi è alcuna differenza significativa tra le proprietà di sicurezza di STARTTLS sulla porta 587 e TLS implicito sulla porta 465 se le implementazioni sono corrette e se sia il client che il server sono configurati per richiedere una negoziazione riuscita di TLS prima dell'invio del messaggio.

La citata appendice A elabora quindi la decisione di preferire il TLS implicito per tutti gli SMTP, POP3 e IMAP, poiché questi punti principali

  1. Vogliamo solo connessioni sono crittografate ovunque in ogni modo, quindi non c'è nessun punto nel mantenere una versione compatibile con le versioni di tutti questi protocolli quando, in pratica, che la compatibilità non viene utilizzato
  2. Ci sono stati exploit della fase di negoziazione STARTTLS a causa di problemi identici in diverse implementazioni
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.