Porte, crittografia e accesso

Modulo 1: Come funziona la posta elettronica · Tempo di lettura: 10 minuti

Obiettivo formativo: Dopo questa lezione sarà in grado di indicare, per ciascuna porta di posta, a cosa serve, di spiegare la differenza tra STARTTLS e TLS diretto, e di interpretare un avviso di certificato o un accesso rifiutato.

Concetti chiave: porta 25, 587, 465, 993, 995, 143, 110, STARTTLS, TLS diretto (implicit TLS, RFC 8314), certificato, nome del server, autenticazione SMTP (SMTP AUTH), open relay, blocco della porta 25, password per app, OAuth

Una porta è una porta d'ingresso

Un server ha un solo indirizzo IP, ma molte porte d'ingresso. Ogni servizio è in ascolto sulla propria porta, un numero. Il Suo browser web bussa alla porta 443, il Suo programma di posta alla porta 993 per leggere la posta e alla 587 o 465 per inviarla. Se sceglie la porta sbagliata, nessuno risponde, oppure risponde qualcuno che parla un'altra lingua. Questo genera messaggi di errore vaghi come "impossibile connettersi" o "il server non risponde".

Le porte di posta in sintesi:

Perché non usare semplicemente la porta 25 per l'invio?

In passato si impostava la porta 25 nel programma di posta. Ciò appartiene al passato per due motivi.

In primo luogo: sulla porta 25 un server di posta accetta messaggi da chiunque, per i propri domini. Non si effettua alcun accesso. Un server che sulla porta 25 inoltra anche la posta di chiunque verso altri domini si chiama open relay, e viene sfruttato dagli spammer entro poche ore. Per questo l'invio della propria posta verso il resto del mondo è diventato un servizio a parte: submission sulla porta 587 (e 465), dove si effettua sempre prima l'accesso.

In secondo luogo: molti provider internet bloccano il traffico in uscita verso la porta 25 dalle connessioni domestiche. Un computer infetto in un salotto non può così inviare spam direttamente ai server di posta. Conseguenza per Lei: se prova a inviare dal Suo programma di posta tramite la porta 25, potrebbe non funzionare a casa e funzionare in ufficio, o viceversa.

Ricordi: i programmi di posta inviano tramite la 587 o la 465, con accesso. La porta 25 è per i server tra loro.

STARTTLS o TLS diretto?

Esistono due modi per crittografare una connessione di posta.

TLS diretto (implicit TLS): la connessione è crittografata fin dal primo byte, come un sito web con https. Avviene sulla 465, 993 e 995.

STARTTLS: la connessione inizia non crittografata. Il server dice "posso crittografare", il client risponde STARTTLS, e da quel momento tutto è crittografato. Avviene sulla 587 (e sulla 25, 143 e 110).

Per la sicurezza fa poca differenza, purché il Suo programma renda STARTTLS obbligatorio. Il rischio di STARTTLS sta nell'inizio: chi si trova tra Lei e il server può eliminare l'offerta "posso crittografare". Un programma che in tal caso prosegue silenziosamente senza crittografia invia la Sua password leggibile sulla linea. Per questo la RFC 8314 (2018) raccomanda ai programmi di posta il TLS diretto (465, 993, 995) rispetto a STARTTLS. In pratica, la 587 con STARTTLS e la 465 con SSL/TLS sono entrambe valide, a condizione di impostare nel Suo programma la crittografia su "obbligatoria" e non su "se disponibile".

Un errore comune è la combinazione sbagliata: porta 587 con "SSL/TLS", oppure porta 465 con "STARTTLS". Il programma si aspetta allora qualcosa di diverso da ciò che fa il server, e la connessione resta bloccata o fallisce. Ricordi le coppie corrette: 587 + STARTTLS e 465 + SSL/TLS. I programmi a volte chiamano il TLS diretto "SSL", "SSL/TLS" o "TLS"; anche STARTTLS viene a volte chiamato "TLS". Guardi quindi alla porta.

Il certificato e il nome del server

Ad ogni connessione crittografata il server mostra un certificato, che dimostra di essere chi dichiara di essere. Il Suo programma di posta verifica due cose: se il certificato è stato rilasciato da un'autorità fidata ed è ancora valido, e se il nome che Lei ha inserito come server vi compare.

Quest'ultimo aspetto è la causa più frequente di problemi. Se inserisce mail.example.com, ma nel certificato compare solo server12.hosting.example, riceverà un messaggio come "Impossibile verificare l'identità del server" o "Il nome principale di destinazione non è corretto". La connessione in sé è comunque crittografata, ma il Suo programma non può avere la certezza di comunicare con il server autentico.

Non ignori un simile avviso cliccando per proseguire. La soluzione è un nome del server che compaia effettivamente nel certificato (vedere lezione 2.1). Con un server condiviso si tratta spesso del nome del server stesso, indicato dal Suo fornitore. Un'altra causa nota: un antivirus che "scansiona" la posta crittografata e inserisce a tale scopo un proprio certificato. Nell'avviso compare allora il nome dello scanner alla voce "rilasciato da".

Accesso per l'invio

Sulla 587 e sulla 465 deve effettuare l'accesso prima che il server accetti di inviare la Sua posta verso l'esterno. Questo si chiama autenticazione SMTP (SMTP AUTH). Nel Suo programma l'opzione si chiama "il server in uscita richiede autenticazione", "accesso richiesto" oppure "autenticazione: password normale". Di norma utilizza lo stesso nome utente e la stessa password usati per IMAP.

Se l'autenticazione è disattivata, o se il nome utente del server in uscita è rimasto vuoto, può leggere la posta ma non inviarla. Il server risponde allora con un messaggio come 530 5.7.0 Authentication required o 554 5.7.1 Relay access denied. Questa è la causa più frequente di "la ricezione funziona, l'invio no".

Un secondo tipo di rifiuto: 535 5.7.8 Authentication failed. In questo caso la combinazione di nome utente e password non è corretta. Attenzione: dopo un certo numero di tentativi falliti, molti server bloccano l'indirizzo IP da cui provengono tali tentativi, come protezione contro il tentativo di indovinare le password. Un vecchio telefono con una password obsoleta può così far bloccare l'intero ufficio.

Password per app e OAuth

Presso i grandi fornitori come Google e Microsoft, l'accesso con la sola password ordinaria in un programma di posta separato funziona sempre meno spesso. Essi utilizzano OAuth: il Suo programma La indirizza a una pagina di accesso del fornitore, Lei vi effettua l'accesso (eventualmente con verifica in due passaggi), e il programma riceve una chiave al posto della Sua password. I programmi che non lo supportano ricevono a volte una password per app: una password separata e lunga, valida solo per quel singolo programma, che può revocare separatamente.

Con una normale casella di posta presso un'azienda di hosting, di norma si accede con la password della casella stessa. Ciò rende ancora più importante una password forte e univoca (lezione 3.4).

In pratica: le impostazioni di una casella di posta

Per una casella di posta di WebOké le impostazioni sono: IMAP 993 con SSL/TLS, POP3 995 con SSL/TLS, invio 587 con STARTTLS oppure 465 con SSL/TLS, autenticazione attiva con il Suo indirizzo e-mail completo e la password della casella. Presso altri fornitori funziona in modo analogo: le porte sono quasi ovunque le stesse, solo il nome del server cambia. Quale nome del server scegliere lo vede nella lezione 2.1.

Riepilogo

• I programmi di posta inviano tramite la 587 (STARTTLS) o la 465 (TLS diretto), sempre con accesso. La porta 25 è per i server tra loro e viene spesso bloccata da casa.
• La lettura avviene tramite la 993 (IMAP) o la 995 (POP3), entrambe con TLS diretto.
• Combini correttamente: 587 + STARTTLS, 465 + SSL/TLS. Imposti la crittografia come obbligatoria.
• Un avviso di certificato significa quasi sempre: il nome del server che ha inserito non compare nel certificato. Ignorarlo cliccando per proseguire non è una soluzione.
• "La lettura funziona, l'invio no" è quasi sempre dovuto a: l'autenticazione per il server in uscita è disattivata o è rimasta vuota.

Quiz

Esercizio

Esercizio Z1.4: Porte e certificato di un server di posta. Inserisca il nome del server in entrata e quello del server in uscita che utilizza per la Sua casella di posta (se non dispone di una casella di posta propria, utilizzi imap.gmail.com e smtp.gmail.com). Per la porta 993 (in entrata) e le porte 465 e 587 (in uscita), indichi ciò che si aspetta: TLS diretto, STARTTLS o non raggiungibile, e indichi se ritiene che il nome compaia nel certificato. Il programma si collega da solo alle tre porte e confronta il risultato con le Sue risposte.

Per approfondire

I passaggi descritti in questi articoli si riferiscono ai pannelli di WebOké; presso altri fornitori il funzionamento è analogo.

• Guida DirectAdmin 8.1: Tutte le impostazioni in un colpo d'occhio: server, porte e sicurezza
• Guida DirectAdmin 8.8: Invio o ricezione non funziona: ecco come risolvere
• Errore del certificato durante la ricezione della posta
• Non riesco a inviare e-mail (la ricezione funziona)
• RFC 8314 (TLS diretto per i programmi di posta), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)