3. Invio di messaggi
3.1. Identificazione dell'invio
La porta 587 è riservata all'invio di messaggi di posta elettronica come specificato in questo documento. I messaggi ricevuti su questa porta sono definiti come invii. Il protocollo utilizzato è ESMTP [SMTP-MTA, ESMTP], con ulteriori restrizioni o autorizzazioni come specificato qui.
Sebbene la maggior parte dei client e dei server di posta elettronica possa essere configurata per utilizzare la porta 587 invece della 25, ci sono casi in cui ciò non è possibile o conveniente. Un sito PUÒ scegliere di utilizzare la porta 25 per l'invio di messaggi, designando alcuni host come MSA e altri come MTA.
3.2. Rifiuto e rimbalzo (bouncing) dei messaggi
Gli MTA e gli MSA POSSONO implementare regole di rifiuto dei messaggi che si basano in parte sul fatto che il messaggio sia un invio o un inoltro.
Ad esempio, alcuni siti potrebbero configurare i propri MTA per rifiutare tutti i comandi RCPT per messaggi che non fanno riferimento a utenti locali e configurare il proprio MSA per rifiutare tutti gli invii di messaggi che non provengono da utenti autorizzati, con autorizzazione basata sull'identità autenticata o sull'endpoint di invio che si trova all'interno di un ambiente IP protetto.
NOTA: è meglio rifiutare un messaggio piuttosto che rischiare di inviarne uno danneggiato. Ciò è particolarmente vero per i problemi correggibili dal MUA, ad esempio un campo 'From' non valido.
Se un MSA non è in grado di determinare un percorso di ritorno (return path) verso l'utente che invia, da un MAIL FROM valido, un indirizzo IP di origine valido o basato sull'identità autenticata, allora l'MSA DOVREBBE rifiutare immediatamente il messaggio. Un messaggio può essere rifiutato immediatamente restituendo un codice 550 al comando MAIL.
Si noti che un percorso di ritorno nullo, ovvero MAIL FROM:<>, è consentito e NON DEVE di per sé essere causa di rifiuto di un messaggio. (I MUA devono generare messaggi con percorso di ritorno nullo per una serie di motivi, incluse le notifiche di disposizione.)
Tranne nel caso in cui l'MSA non sia in grado di determinare un percorso di ritorno valido per il messaggio inviato, il testo in questa specifica che istruisce un MSA a emettere un codice di rifiuto PUÒ essere rispettato accettando il messaggio e generando successivamente un messaggio di rimbalzo. (Cioè, se l'MSA rifiuterà un messaggio per qualsiasi motivo tranne l'impossibilità di determinare un percorso di ritorno, può facoltativamente effettuare un rifiuto immediato o accettare il messaggio e poi inviare un rimbalzo.)
NOTA: nel caso normale di invio di messaggi, è preferibile rifiutare immediatamente il messaggio, in quanto fornisce all'utente e al MUA un feedback diretto. Per gestire correttamente i rimbalzi ritardati, il MUA client deve mantenere una coda di messaggi che ha inviato e abbinare i rimbalzi ad essi. Si noti che molti MUA contemporanei non hanno questa capacità.
3.3. Invio autorizzato
Sono stati utilizzati numerosi metodi per garantire che solo gli utenti autorizzati siano in grado di inviare messaggi. Questi metodi includono SMTP autenticato, restrizioni dell'indirizzo IP, IP sicuro e altri tunnel e autenticazione POP precedente.
SMTP autenticato [SMTP-AUTH] ha visto un'ampia diffusione. Consente all'MSA di determinare un'identità di autorizzazione per l'invio del messaggio, che non è legata ad altri protocolli.
Le restrizioni dell'indirizzo IP sono implementate molto ampiamente, ma non consentono viaggiatori e situazioni simili e possono essere facilmente falsificate a meno che tutti i percorsi di trasporto tra MUA e MSA non siano affidabili.
IP sicuro [IPSEC] e altre tecniche di tunneling crittografato e autenticato possono essere utilizzate e offrono ulteriori vantaggi di protezione contro le intercettazioni e l'analisi del traffico.
È stato utilizzato anche richiedere un'autenticazione POP [POP3] (dallo stesso indirizzo IP) entro un certo periodo di tempo (ad esempio, 20 minuti) prima dell'inizio di una sessione di invio di messaggi, ma ciò impone restrizioni ai client così come ai server, il che può causare difficoltà. Nello specifico, il client deve eseguire un'autenticazione POP prima di una sessione di invio SMTP e non tutti i client sono in grado e configurati per questo. Inoltre, l'MSA deve coordinarsi con il server POP, il che potrebbe essere difficile. C'è anche una finestra durante la quale un utente non autorizzato può inviare messaggi e apparire come un utente precedentemente autorizzato. Poiché dipende dagli indirizzi IP del MUA, questa tecnica è sostanzialmente soggetta allo spoofing dell'indirizzo IP quanto la convalida basata solo su indirizzi IP noti (vedere sopra).