1. Introduzione

SMTP è stato definito come un protocollo di trasferimento di messaggi, ovvero un mezzo per instradare (se necessario) e consegnare messaggi finiti (completi).

I Message Transfer Agent (MTA) non dovrebbero alterare il testo del messaggio, tranne per aggiungere campi di intestazione 'Received', 'Return-Path' e altri come richiesto da [SMTP-MTA].

Tuttavia, SMTP è ora ampiamente utilizzato anche come protocollo di invio (submission) di messaggi, ovvero un mezzo per i Message User Agent (MUA) per introdurre nuovi messaggi nella rete di routing MTA. Il processo che accetta l'invio di messaggi dai MUA è denominato Message Submission Agent (MSA).

Al fine di consentire comunicazioni non vincolate, SMTP non è spesso autenticato durante l'inoltro dei messaggi.

L'autenticazione e l'autorizzazione degli invii iniziali sono diventate sempre più importanti, guidate dai cambiamenti nei requisiti di sicurezza e dalle crescenti aspettative che i server di invio si assumano la responsabilità del traffico di messaggi che originano.

Ad esempio, a causa della prevalenza di macchine che hanno worm, virus o altro software dannoso che generano grandi quantità di spam, molti siti ora vietano il traffico in uscita sulla porta SMTP standard (porta 25), incanalando tutti gli invii di posta attraverso i server di invio.

Oltre ai problemi di autenticazione e autorizzazione, i messaggi inviati sono in alcuni casi messaggi finiti (completi) e in altri casi non finiti (incompleti) in uno o più aspetti. Potrebbe essere necessario completare i messaggi non finiti per garantire che siano conformi a [MESSAGE-FORMAT] e ai requisiti successivi. Ad esempio, il messaggio potrebbe non avere un campo di intestazione 'Date' corretto e i domini potrebbero non essere completamente qualificati. In alcuni casi, il MUA potrebbe non essere in grado di generare messaggi finiti (ad esempio, potrebbe non conoscere il proprio fuso orario). Anche quando i messaggi inviati sono completi, la policy del sito locale potrebbe imporre che il testo del messaggio venga esaminato o modificato in qualche modo, ad esempio per nascondere nomi o spazi di indirizzi locali. Tali completamenti o modifiche hanno dimostrato di causare danni se eseguiti da MTA a valle - ovvero MTA dopo il primo MTA di invio - e sono in generale considerati al di fuori della competenza della funzionalità MTA standardizzata.

La separazione dei messaggi in invii e trasferimenti consente agli sviluppatori e agli amministratori di rete di eseguire più facilmente le seguenti operazioni:

• Implementare policy di sicurezza e proteggersi dall'inoltro di posta non autorizzato o dall'iniezione di posta indesiderata (bulk mail)

• Implementare l'invio autenticato, incluso l'invio fuori sede da parte di utenti autorizzati come i viaggiatori

• Separare le differenze di codice software rilevanti, rendendo così ogni base di codice più semplice e consentendo programmi diversi per l'inoltro e l'invio

• Rilevare problemi di configurazione con i client di posta di un sito

• Fornire una base per aggiungere servizi di invio avanzati in futuro

Questo memorandum descrive un mezzo a basso costo e deterministico affinché i messaggi siano identificati come invii e specifica quali azioni devono essere intraprese da un server di invio.