8. Modifiche ai messaggi

I siti POSSONO modificare gli invii per garantire la conformità agli standard e alla policy del sito. Questa sezione descrive una serie di tali modifiche che sono spesso considerate utili.

NOTA: come guida per le decisioni locali di implementare la modifica dei messaggi, una regola fondamentale è limitare tali azioni ai rimedi per problemi specifici che hanno soluzioni chiare. Ciò è particolarmente vero con gli elementi dell'indirizzo. Ad esempio, aggiungere indiscriminatamente un dominio a un indirizzo o elemento che ne è privo in genere si traduce in più indirizzi interrotti. Un indirizzo non qualificato deve essere verificato come una parte locale valida nel dominio prima che il dominio possa essere aggiunto in sicurezza.

Qualsiasi messaggio inoltrato o consegnato dall'MSA DEVE essere conforme ai requisiti di [SMTP-MTA] e [MESSAGE-FORMAT].

8.1. Aggiungere 'Sender'

L'MSA PUÒ aggiungere o sostituire il campo 'Sender', se l'identità del mittente è nota e questa non è fornita nel campo 'From'.

L'MSA DEVE garantire che qualsiasi indirizzo che inserisce in un campo 'Sender' sia in effetti un indirizzo di posta valido.

8.2. Aggiungere 'Date'

L'MSA PUÒ aggiungere un campo 'Date' al messaggio inviato, se ne è privo, o correggere il campo 'Date' se non è conforme alla sintassi [MESSAGE-FORMAT].

8.3. Aggiungere 'Message-ID'

L'MSA DOVREBBE aggiungere o sostituire il campo 'Message-ID', se ne è privo, o se non è una sintassi valida (come definita da [MESSAGE-FORMAT]). Si noti che un certo numero di client non genera ancora campi Message-ID.

8.4. Codifica di trasferimento

L'MSA PUÒ applicare la codifica di trasferimento al messaggio secondo le convenzioni MIME, se necessario e non dannoso per il tipo MIME.

8.5. Firmare il messaggio

L'MSA PUÒ firmare (digitalmente) o aggiungere in altro modo informazioni di autenticazione al messaggio.

8.6. Crittografare il messaggio

L'MSA PUÒ crittografare il messaggio per il trasporto per riflettere le policy organizzative.

NOTA: per essere utile, l'aggiunta di una firma e/o crittografia da parte dell'MSA implica generalmente che la connessione tra il MUA e l'MSA debba essere essa stessa protetta in qualche altro modo, ad esempio operando all'interno di un ambiente sicuro, proteggendo la connessione di invio al livello di trasporto o utilizzando un meccanismo [SMTP-AUTH] che fornisce l'integrità della sessione.

8.7. Risolvere gli alias

L'MSA PUÒ risolvere gli alias (record CNAME) per i nomi di dominio, nella busta SMTP e facoltativamente nei campi di indirizzo dell'intestazione, soggetto alla policy locale.

NOTA: la risoluzione incondizionata degli alias potrebbe essere dannosa. Ad esempio, se www.example.net e ftp.example.net sono entrambi alias per mail.example.net, riscriverli potrebbe far perdere informazioni utili.

8.8. Riscrizione dell'intestazione

L'MSA PUÒ riscrivere le parti locali e/o i domini nella busta SMTP e facoltativamente nei campi di indirizzo dell'intestazione, secondo la policy locale. Ad esempio, un sito potrebbe preferire riscrivere 'JRU' come 'J.Random.User' per nascondere i nomi di accesso e/o riscrivere 'squeaky.sales.example.net' come 'zyx.example.net' per nascondere i nomi delle macchine e rendere più facile lo spostamento degli utenti.

Tuttavia, dovrebbero essere modificati solo gli indirizzi, le parti locali o i domini che corrispondono a specifiche impostazioni di configurazione MSA locali. Sarebbe molto pericoloso per l'MSA applicare regole di riscrittura indipendenti dai dati, come l'eliminazione sempre del primo elemento di un nome di dominio. Quindi, ad esempio, una regola che rimuove l'elemento più a sinistra del dominio, se il dominio completo corrisponde a '*.foo.example.net', sarebbe accettabile.

L'MSA NON DEVE riscrivere un indirizzo di inoltro (destinazione) in un modo che violi i vincoli di [SMTP-MTA] sulle modifiche delle parti locali.