Questo articolo esamina le sfide legate all’uso della crittografia delle email e dei servizi di inoltro privato con Zendesk, evidenziando i problemi relativi al mantenimento della sicurezza e all’anonimato del mittente. Vengono inoltre discussi i diversi tipi di crittografia delle email e le implicazioni degli inoltri di email private per le funzionalità di Zendesk.
Questo articolo contiene le seguenti sezioni:
- Informazioni sui limiti dell’uso della crittografia email e dei servizi di inoltro con Zendesk
- Informazioni sulla crittografia delle email
- Informazioni sugli inoltri email privati
Informazioni sui limiti dell’uso della crittografia email e dei servizi di inoltro con Zendesk
Sta diventando sempre più comune per le organizzazioni inviare email usando la crittografia delle emailo tramite un servizio di inoltro email privatoche maschera l’identità email e il dominio del mittente originale.
Sebbene sia possibile che uno di questi due sistemi funzioni con Zendesk, il risultato dipende in gran parte dallo stato dell’email inviata o inoltrata e dalla forma in quella parte del processo di inoltro. Per i servizi email privati, il successo dipende da come mantengono la coerenza del thread di conversazione e aderiscono ai protocolli che consentono ciò.
Laddove possibile e assicurandoti di essere in conformità con tutti gli accordi o i requisiti legali, di sicurezza e privacy, è meglio inviare o inoltrare a Zendesk un’email non crittografata quando puoi verificare di farlo in modo sicuro.
Zendesk non può decrittografare un’email per te come se fossimo il destinatario designato e possediamo l’identità necessaria per agire in base all’email o per fornirti informazioni utili sul mittente che ti ha inviato l’email usando un servizio di inoltro privato. Lo scopo della crittografia (che richiede l’autenticazione per il processo di decrittografia) è prevenire l’intercettazione indesiderata di informazioni. Zendesk funge da repository di informazioni, ma spesso svolge il ruolo di intermediario nel processo generale. Lo scopo degli inoltri email privati è nascondere l’identità del mittente e il vero dominio del mittente.
Sebbene la decrittografia delle email o la determinazione dell’identità di un mittente mascherato siano quasi impossibili da un punto di vista matematico, tentare di decrittografarle costituirebbe una violazione delle nostre politiche di sicurezza e privacy e forse una violazione delle leggi sulla privacy statali o federali.
Zendesk ha la responsabilità di preservare la sicurezza delle comunicazioni, inclusi i servizi di invio di email crittografate o private.
Informazioni sulla crittografia delle email
Attualmente sono in uso alcune forme di crittografia delle email . I due più usati sono S/MIME e PGP/MIME.
- S/MIME (Secure/MIME) è il più usato, in quanto è integrato nell’infrastruttura di diversi provider email di grandi dimensioni: OSX, iOS, Outlook, Gmail, ecc.
- PGP/MIME (PrettyGoodPrivacy/MIME) si basa su un modello decentralizzato e su uno strumento di crittografia di terzi.
Ce ne sono molti altri, inclusi protocolli di crittografia interamente proprietari. Alcuni di questi funzionano solo quando l’email è in transito, quindi sono invisibili agli utenti finali che visualizzano le email nei loro client autenticati. Altri richiedono un’autenticazione rigorosa da parte dell’utente prima che l’email possa essere leggibile da un essere umano. Quando un’email viene inoltrata a un altro servizio, come spesso accade quando arriva ai server di elaborazione in ingresso di Zendesk, dipendiamo interamente dallo stato di crittografia in cui arriva l’email.
Zendesk attualmente supporta solo opportunistic-TLS come protocollo di crittografia email end-to-end. Ciò significa che, sia in ingresso che in uscita, accetteremo o invieremo email crittografate con TLS se anche il server di invio o destinatario supporta tale protocollo. Ecco l’ articolo di panoramica delle nostre funzioni di sicurezza.
Funzioni Zendesk che usano la crittografia TLS
Se hai esigenze di crittografia delle email, offriamo tre funzioni che usano la crittografia TLS: Connettore Exchange, Connettore Gmaile Connettore SMTP autenticato.
Le prime due funzionalità recuperano e inoltrano le email al provider tramite chiamate API, che sono sempre crittografate con SSL/TLS. Il connettore SMTP autenticato usa anche la crittografia TLS su SMTP in quanto richiede un nome utente e una password, che devono essere crittografati prima di essere inviati o ricevuti. La versione solo in uscita di questa funzione è crittografata solo per il traffico in uscita, ma il TLS forzato può essere abilitato sul servizio di invio/inoltro per raggiungere un obiettivo simile, garantendo la crittografia in transito.
Il connettore Gmail può ricorrere all’invio dalla nostra infrastruttura se vengono superati i limiti di frequenza, dove la crittografia TLS è sempre offerta per gli inoltri in uscita ma non è garantita, in quanto dipende dal server di ricezione che accetta la connessione TLS.
Informazioni sugli inoltri email privati
Questi servizi sono progettati per nascondere l’identità del mittente. Nelle circostanze migliori, interagiamo normalmente, anche se con un indirizzo email proxy.
I problemi in genere si verificano nell’uso degli indirizzi Reply-To: tokenizzati. Questi campi di intestazione indicano a un servizio email del destinatario l’indirizzo a cui inviare la risposta. Diventa l’indirizzo nel campo A: del client email (MS Outlook, Mac Mail, Gmail, Yahoo, ecc.) quando fai clic su Rispondi o Rispondi a tutti. Gli inoltri email privati devono necessariamente compilare questo campo con un indirizzo email diverso dall’indirizzo email del mittente originale, altrimenti l’inoltro non sarebbe privato.
Spesso, questi servizi si basano su un indirizzo tokenizzato che può essere analizzato e indirizzato solo in base alla stringa tokenizzata che si trova nella parte locale dell’indirizzo email, nonché alla parte di dominio dell’indirizzo email che riflette la risorsa dell’inoltro email privato anziché mittente originale. Questi token sono protetti dalla conversione da parte di un destinatario come aspetto fondamentale del servizio che stanno fornendo. Poiché questi servizi sono progettati per la massima protezione dell’identità degli utenti, il servizio destinatario può interrompere la consegna di qualsiasi tentativo di email se l’utente sceglie di terminare il thread email. Questo comportamento proibitivo è completamente al di fuori del controllo del server di invio per la negoziazione.
Zendesk è consapevole dell’importanza di qualsiasi comunicazione da parte del cliente a te, ed è altrettanto importante che i mittenti di questo tipo di email desiderino che le proprie informazioni vengano visualizzate solo dal destinatario a cui sono state designate. Se ci stai inoltrando un’email, il tuo indirizzo di inoltro potrebbe essere il destinatario previsto. L’accesso alla posta in arrivo indirizzo di assistenza per l’inoltro potrebbe offrire informazioni utili per ottenere maggiori informazioni su questi tipi di inoltri email.
Avvertenza sulla traduzione: questo articolo è stato tradotto usando un software di traduzione automatizzata per fornire una comprensione di base del contenuto. È stato fatto tutto il possibile per fornire una traduzione accurata, tuttavia Zendesk non garantisce l'accuratezza della traduzione.
Per qualsiasi dubbio sull'accuratezza delle informazioni contenute nell'articolo tradotto, fai riferimento alla versione inglese dell'articolo come versione ufficiale.