4. Terminologia

Questo documento presuppone una ragionevole comprensione dei protocolli e della terminologia degli standard fondamentali dell'email come documentati nell'RFC 5321 [RFC5321] e nell'RFC 5322 [RFC5322].

4.1. Mail User Agent e Mail Transfer Agent

Gran parte della descrizione in questo documento si basa sulle astrazioni di "Mail Transfer Agent" ("MTA") e "Mail User Agent" ("MUA"). Tuttavia, è importante comprendere che tali termini e i concetti sottostanti sono posteriori alla progettazione dell'architettura email di Internet e all'applicazione ad essa del principio dei "protocolli sul filo" ("protocols on the wire"). Tale architettura email, così come si è evoluta, e tale principio "on the wire" hanno impedito qualsiasi distinzione forte e standardizzata su come MTA e MUA interagiscano su un dato host di origine o di destinazione (o persino se siano separati).

Tuttavia, il termine "final delivery MTA" è usato in questo documento in modo equivalente al termine "delivery system" o "final delivery system" dell'RFC 5321. Si tratta del server SMTP che controlla il formato delle parti locali degli indirizzi ed è autorizzato a ispezionarle e interpretarle. Esso riceve messaggi dalla rete per la consegna alle caselle postali o per altre elaborazioni locali, inclusi eventuali inoltri o alias che modificano gli indirizzi di busta, anziché per l'inoltro (relaying). Dal punto di vista della rete, qualsiasi disposizione di consegna locale — come il salvataggio in un archivio messaggi, la consegna a programmi o agenti specifici di recapito dei messaggi e i meccanismi di recupero dei messaggi — si trova "dietro" il final delivery MTA e quindi non fa parte del processo di trasporto o consegna SMTP.

4.2. Set di caratteri degli indirizzi

In questo documento, un indirizzo è "all-ASCII", o semplicemente un "indirizzo ASCII", se ogni carattere dell'indirizzo appartiene al repertorio di caratteri ASCII [ASCII]; un indirizzo è "non-ASCII", o un "i18n-address", se un qualsiasi carattere non appartiene al repertorio di caratteri ASCII. Tali indirizzi MAY essere limitati in altri modi, ma tali restrizioni non sono rilevanti ai fini di questa definizione. Il termine "all-ASCII" è applicato anche ad altri elementi di protocollo quando la distinzione è importante, con "non-ASCII" o "internazionalizzato" come suo opposto.

Il termine ombrello per descrivere l'internazionalizzazione degli indirizzi email specificata da questo documento e dai documenti che lo accompagnano è "SMTPUTF8". Per esempio, un indirizzo consentito da questa specifica è indicato come "indirizzo (conforme a) SMTPUTF8".

Si noti che, secondo le definizioni qui fornite, l'insieme di tutti gli indirizzi "all-ASCII" e l'insieme di tutti gli indirizzi "non-ASCII" sono mutuamente esclusivi. L'insieme di tutti gli indirizzi consentiti quando compare SMTPUTF8 è l'unione di questi due insiemi.

4.3. Tipi di utente

Un "utente ASCII" (i) utilizza esclusivamente indirizzi email che contengono solo caratteri ASCII e (ii) non è in grado di generare indirizzi di destinatario che contengano caratteri non-ASCII.

Un "utente di email internazionalizzate" possiede uno o più indirizzi email non-ASCII, oppure è in grado di generare indirizzi di destinatario che contengono caratteri non-ASCII. Tale utente può possedere anche indirizzi ASCII; se l'utente ha più di un account email e un indirizzo corrispondente, o più di un alias per lo stesso indirizzo, dispone di un qualche metodo per scegliere quale indirizzo usare nell'email in uscita. Si noti che, secondo questa definizione, non è possibile stabilire da un indirizzo ASCII se il titolare di tale indirizzo sia un utente di email internazionalizzate oppure no. (Un indirizzo non-ASCII implica la convinzione che il titolare di tale indirizzo sia un utente di email internazionalizzate.) Non esiste alcunché come un "messaggio di utente di email internazionalizzate"; il termine si applica solo agli utenti e ai loro agenti e capacità. In particolare, l'uso di contenuto di messaggio non-ASCII, e quindi presumibilmente internazionalizzato, è parte integrante delle specifiche MIME [RFC2045] e non richiede queste estensioni (sebbene sia compatibile con esse).

4.4. Messaggi

Un "messaggio" è inviato da un utente (il mittente) che utilizza un particolare indirizzo email a uno o più altri indirizzi email di destinatari (spesso indicati semplicemente come "utenti" o "utenti destinatari").

4.5. Liste di distribuzione

Una "lista di distribuzione" è un meccanismo mediante il quale un messaggio può essere distribuito a più destinatari inviandolo a un unico indirizzo di destinatario. Un agente (tipicamente non una persona) a quell'unico indirizzo fa quindi sì che il messaggio venga ridistribuito ai destinatari previsti. Questo agente imposta l'indirizzo di ritorno della busta del messaggio ridistribuito su un indirizzo diverso da quello del messaggio originale inviato all'unico destinatario. L'uso di un indirizzo di ritorno della busta diverso (reverse-path) fa sì che i messaggi di errore (e altri messaggi generati automaticamente) vadano a un indirizzo di gestione degli errori.

Disposizioni speciali per la gestione delle liste di distribuzione che potrebbero contenere indirizzi non-ASCII sono discusse in un documento specifico su tale argomento [RFC5983] e nel suo successore previsto [RFC5983bis-MailingList].

4.6. Messaggio convenzionale e messaggio internazionalizzato

• Un messaggio convenzionale è un messaggio che non utilizza alcuna estensione definita nel documento sull'estensione SMTP [RFC6531] o nel documento UTF8header [RFC6532] di questo insieme di specifiche, ed è strettamente conforme all'RFC 5322 [RFC5322].

• Un messaggio internazionalizzato è un messaggio che utilizza una o più delle estensioni definite in questo insieme di specifiche, cosicché non è più conforme alla specifica tradizionale di un messaggio email o del suo trasporto.

4.7. Messaggi non recapitabili, notifiche e ricevute di consegna

Come specificato nell'RFC 5321, un messaggio non recapitabile per qualche ragione dovrebbe comportare una notifica al mittente. Ciò può avvenire in due modi. Il primo, tipicamente chiamato "Rejection" (rifiuto), si verifica quando un server SMTP restituisce un codice di risposta che indica un errore fatale (un codice "5yz") o restituisce in modo persistente un errore di fallimento temporaneo (un codice "4yz"). L'altro comporta l'accettazione del messaggio durante l'elaborazione SMTP e la successiva generazione di un messaggio al mittente, tipicamente noto come "Non-delivery Notification" o "NDN". La prassi corrente spesso preferisce il rifiuto rispetto agli NDN, a causa della minore probabilità che la generazione di NDN venga usata come tecnica di spam. Quest'ultimo caso, quello degli NDN, è inevitabile se un MTA intermedio accetta un messaggio che viene poi rifiutato dal server di next-hop.

Un mittente MAY anche richiedere esplicitamente ricevute di messaggio [RFC3461] che sollevano, per queste estensioni di internazionalizzazione, gli stessi problemi degli NDN.