Da questa pagina puoi configurare le opzioni Transport Layer Security per l'MTA.
TLS garantisce senza soluzione di continuità la crittografia del trasporto delle email per la consegna via SMTP tra server che la supportano.
Impostazioni TLS
Libraesva ESG gestisce sia la ricezione che l'invio delle email, quindi il TLS può essere configurato su entrambi i lati: puoi definire policy diverse in ricezione (server) o in invio (client). La policy predefinita per le connessioni in entrata e in uscita può essere una delle seguenti:- none (nessun TLS in ricezione)
- may (tenta di negoziare una connessione TLS, questa è l'impostazione predefinita)
- encrypt (forza una connessione TLS in ricezione e, se fallisce, non accetta la posta in entrata)
Per-destination SMTP/TLS client policy maps
È possibile specificare una policy TLS diversa per le destinazioni di next-hop. Questa impostazione sovrascrive le impostazioni predefinite per le connessioni in uscita. Ogni policy è definita da 3 parametri:- Destination (la destinazione next-hop come dominio, server di posta o indirizzo IP. Quando specifichi un server di posta o un IP, includilo tra parentesi quadre [1.2.3.4])
-
Policy
- None (nessun TLS)
- May (TLS opportunistico. Sono disponibili gli attributi opzionali "ciphers", "exclude" e "protocols")
- Encrypt (crittografia obbligatoria. La posta viene consegnata solo se il server SMTP remoto offre STARTTLS e l'handshake TLS ha successo. A questo livello e superiori, sono disponibili gli attributi opzionali "protocols", "ciphers" e "exclude")
- Dane (crittografia obbligatoria. La posta viene consegnata solo se il server SMTP remoto offre STARTTLS e l'handshake TLS ha successo. A questo livello e superiori, sono disponibili gli attributi opzionali "protocols", "ciphers" e "exclude")
- Dane-only (TLS DANE obbligatorio. La policy TLS per la destinazione viene ottenuta tramite record TLSA in DNSSEC. Se non vengono trovati record TLSA, o nessuno è utilizzabile, non viene stabilita alcuna connessione al server)
- Fingerprint (verifica dell'impronta digitale (fingerprint) del certificato. A questo livello di sicurezza non ci sono autorità di certificazione affidabili. La catena di fiducia del certificato e la data di scadenza non vengono verificate. Invece, l'attributo opzionale "match" elenca le impronte digitali del certificato server o delle chiavi pubbliche. L'algoritmo di digest utilizzato per calcolare le impronte digitali è SHA256. È possibile combinare più impronte digitali con un delimitatore "|" in un unico attributo match)
- Verify (verifica obbligatoria del certificato server. La posta viene consegnata solo se l'handshake TLS ha successo, se il certificato del server SMTP remoto può essere convalidato (non scaduto o revocato, e firmato da un'autorità di certificazione affidabile), e se il nome del certificato server corrisponde all'attributo opzionale "match")
- Secure (TLS a canale sicuro. A questo livello di sicurezza, le ricerche DNS MX, sebbene potenzialmente utilizzate per determinare gli indirizzi IP candidati del gateway next-hop, non sono considerate sufficientemente affidabili per la verifica del nome peer TLS. Invece, il nome predefinito verificato nel certificato server viene ottenuto direttamente dal next hop oppure specificato esplicitamente tramite l'attributo opzionale match. L'attributo match è particolarmente utile quando più domini sono gestiti da un server comune: le voci di policy per i domini aggiuntivi specificano regole di corrispondenza per il certificato del dominio primario. Sebbene le sostituzioni della tabella di trasporto che instradano i domini secondari verso il next-hop primario consentano anch'esse una verifica sicura, comportano il rischio di consegna alla destinazione sbagliata quando i domini cambiano proprietario o vengono riassegnati a nuovi gateway. Con l'approccio dell'attributo "match", l'instradamento non viene alterato e la posta viene rinviata se la verifica di un nuovo host MX fallisce)
- Attribute (specifica un attributo di policy opzionale)