6. Considerazioni

6.1. Considerazioni sulla Sicurezza

Questo documento descrive l'architettura di posta Internet esistente. Non introduce nuove funzionalità. Le considerazioni sulla sicurezza di questa architettura distribuita sono documentate estensivamente nelle specifiche tecniche referenziate da questo documento. Tali specifiche coprono argomenti di sicurezza classici, come l'autenticazione e la privacy. Ad esempio, i protocolli di trasferimento email possono utilizzare meccanismi standardizzati per operare su collegamenti autenticati e/o crittografati, e i payload dei messaggi hanno standard di protezione simili. Esempi di tali meccanismi includono SMTP-TLS [RFC3207], SMTP-Auth [RFC4954], OpenPGP [RFC4880], e S/MIME [RFC3851].

Il cuore dell'architettura di posta Internet non impone requisiti o funzioni di sicurezza sui componenti end-to-end o hop-by-hop. Ad esempio, non richiede l'autenticazione dei partecipanti e non tenta di impedire la divulgazione dei dati.

Particolari attributi del messaggio possono esporre specifiche considerazioni sulla sicurezza. Ad esempio, la funzionalità di copia per conoscenza nascosta (blind carbon copy) dell'architettura invita a preoccupazioni sulla divulgazione, come discusso nella Sezione 7.2 di [RFC5321] e nella Sezione 5 di [RFC5322]. Il trasporto di contenuti testuali o non testuali in questa architettura ha considerazioni sulla sicurezza discusse in [RFC5322], [RFC2045], [RFC2046], e [RFC4288]; inoltre, considerazioni sulla sicurezza sono presenti per alcuni dei tipi di media registrati presso IANA.

Gli agenti che rispondono automaticamente alle email sollevano significative considerazioni sulla sicurezza, come discusso in [RFC3834]. I comportamenti dei gateway influenzano i servizi di sicurezza end-to-end, come discusso in [RFC2480]. Le considerazioni sulla sicurezza per i filtri di confine sono discusse in [RFC5228].

Vedere la Sezione 7.1 di [RFC5321] per una discussione sul tema della convalida dell'origine. Come menzionato nella Sezione 4.1.4, è comune che i componenti di questa architettura utilizzino RFC0791.SourceAddr per prendere decisioni sulle policy [RFC2505], sebbene l'indirizzo possa essere falsificato ("spoofed"). È possibile utilizzarlo senza autorizzazione. L'autenticazione SMTP e di sottomissione ([RFC4409], [RFC4954]) fornisce alternative più sicure.

La discussione sui confini di fiducia, ADMD, Attori, ruoli e responsabilità in questo documento evidenzia la rilevanza e la potenziale complessità dei fattori di sicurezza per il funzionamento di un servizio di posta Internet. Il design di base della posta Internet per incoraggiare lo scambio di messaggi aperto e casuale ha incontrato sfide di scalabilità man mano che la popolazione dei partecipanti all'email è cresciuta fino a includere coloro che hanno pratiche problematiche. Ad esempio, lo spam, come definito in [RFC2505], è un sottoprodotto di questa architettura. Sono stati emessi numerosi documenti Standards Track o BCP sull'argomento (vedere [RFC2505], [RFC5068], e [RFC5235]).

6.2. Internazionalizzazione

Gli standard fondamentali della posta elettronica Internet si basano sull'uso di US-ASCII -- in particolare SMTP [RFC5321] e IMF [RFC5322], così come i loro predecessori. Descrivono il trasporto e la composizione dei messaggi come costituiti rigorosamente da caratteri codificati a 7 bit US-ASCII. Gli standard sono stati progressivamente migliorati per consentire caratteri al di fuori di questo set limitato, pur mantenendo meccanismi per la retrocompatibilità. Nello specifico:

• Le specifiche MIME ([RFC2045], [RFC2046], [RFC2047], [RFC2049]) consentono l'uso di set di caratteri codificati e schemi di codifica dei caratteri ("charsets" nella terminologia MIME) diversi da US-ASCII. [RFC2046] di MIME consente al contenuto testuale di un messaggio di avere un'etichetta apposta che specifica il set di caratteri utilizzato in quel contenuto. Allo stesso modo, [RFC2047] di MIME consente al contenuto testuale di determinati campi di intestazione in un messaggio di essere etichettato in modo simile. Tuttavia, poiché i messaggi potrebbero essere trasportati su implementazioni SMTP in grado di trasportare solo caratteri codificati a 7 bit, [RFC2045] di MIME fornisce anche "codifiche di trasferimento del contenuto" (content transfer encodings) in modo che i caratteri di altri set di caratteri possano essere ricodificati come sovrapposizione a US-ASCII.

• [RFC2045] di MIME consente al contenuto testuale di un messaggio di essere in uno schema di codifica dei caratteri a 8 bit. Per trasportarli senza ricodifica, la specifica SMTP supporta un'opzione [RFC1652] che consente il trasporto di tale contenuto testuale. Tuttavia, l'opzione [RFC1652] non affronta l'uso di contenuto a 8 bit nei campi di intestazione del messaggio, e quindi la codifica [RFC2047] è ancora richiesta per quelli.

• È stata rilasciata una serie di protocolli sperimentali sull'Internazionalizzazione degli Indirizzi Email (EAI), che estendono SMTP e IMF per consentire ai caratteri codificati a 8 bit di apparire negli indirizzi e in altre informazioni in tutti i campi di intestazione dei messaggi. [RFC5335] specifica il formato di tali campi di intestazione del messaggio (che codificano i caratteri in UTF-8), e [RFC5336] specifica un'opzione SMTP per il trasporto di questi messaggi.

• [RFC2045] e [RFC2046] di MIME consentono il trasporto di vero materiale multimediale; tale materiale consente intrinsecamente l'internazionalizzazione poiché non è limitato a nessuna lingua o locale particolare.

• I formati per le Notifiche dello Stato di Consegna (DSN -- [RFC3462], [RFC3463], [RFC3464]) e per le Notifiche di Disposizione del Messaggio (MDN -- [RFC3798]) includono sia una rappresentazione strutturata che una non strutturata della notifica. Nel caso in cui la rappresentazione non strutturata sia nella lingua sbagliata o sia altrimenti inadatta all'uso, ciò consente a un MUA di costruire la propria rappresentazione della notifica appropriatamente localizzata per la visualizzazione all'Utente.

• POP e IMAP non hanno difficoltà a gestire i messaggi MIME, inclusi quelli contenenti 8 bit, e quindi non sono una fonte di problemi di internazionalizzazione.

Pertanto, l'uso di UTF-8 è pienamente stabilito nella posta Internet esistente. Tuttavia, il supporto per le forme di codifica di lunga data viene mantenuto ed è ancora in uso.