Una delle difficoltà nel mettere in sicurezza SMTP risiede nel protocollo stesso, in particolare le ammonizioni in RFC 5321 che forniscono le proscrizioni sulla tempistica di una sessione. Un'implementazione fedele non offre alcuna possibilità di programmare una sessione. Idealmente si vorrebbe ignorare tali raccomandazioni e impostare un timeout della sessione per la sessione di posta. Ciò impedirà ad esempio eventuali attacchi in cui vengono utilizzati lunghi ritardi per l'invio di dati carattere per carattere con grandi dimensioni della posta. Ad esempio, se si dispone di un server di posta con un limite di dimensioni della posta di 10 MB, è abbastanza facile scrivere uno script che recapita una mail falsa sul server e scrive un messaggio Lorem Ipsum, un carattere alla volta fino al limite di 10 MB, ma ritardare ogni carattere di 1 - 2 minuti. In teoria, senza un limite di sessione, una tale sessione di posta elettronica potrebbe durare circa 10 milioni di minuti. Quindi ora esegui uno script che avvia semplicemente i robot che fanno questo da centinaia di punti sul web, e molto presto i robot avranno tutte le connessioni legate (supponendo che tu abbia dei limiti di connessione, o stiano usando un pool di connessioni).
Idealmente, si dovrebbe impostare un timer dal momento in cui il comando DATA è stato emesso al momento in cui è stato emesso il "CRLF .CRLF". Qualcosa come 5 minuti o così per l'intera trasmissione dei dati dovrebbe essere ragionevole. E violare la RFC e semplicemente rilasciare la connessione se supera questo timeout. I clienti ben educati non si avvicinano mai a questo limite e anche le persone che usano il terminale a riga di comando dovrebbero essere in grado di inviare dati entro quel lasso di tempo presumendo che sappiano come digitare.