A maioria dos MTAs vai para praticamente qualquer fim para evitar deixar cair uma mensagem no chão. Normalmente, uma rejeição será gerada (pelo MTA receptor ou, para MTAs com comportamento melhor, o MTA de recebimento recusará com um código de erro fatal 5xx e o MTA remetente converterá a mensagem de saída em uma devolução).
Se essa rejeição não puder ser entregue, o MTA que a mantém normalmente a enviará para o destinatário do último recurso, que é o postmaster local.
Somente se o MTA não puder fazer qualquer coisa com ele - e isso normalmente requer que você configure ativamente não - ele entrará em pânico e destruirá a mensagem. Mesmo assim, você normalmente encontrará uma entrada de log semelhante a
Oct 24 04:18:57 host sm-mta[4499]: g9N5EwE3004499: Losing q5/qfg9N5EwE3004499: savemail panic
Oct 24 04:18:57 host sm-mta[4499]: g9N5EwE3004499: SYSERR(root): savemail: cannot save rejected email anywhere
Então, meu conselho é começar no sistema em que o e-mail foi gerado e seguir as entradas de log. Isso pode ser bastante forense, e muitas vezes pode cruzar vários sistemas diferentes (e se os relógios não estiverem sincronizados, você irá lamentar o dia em que decidiu não instalar o NTP!) Mas, no final, todos os bons MTAs mantêm registros excelentes e Depois de entender como eles são escritos, eles serão adicionados.
Eventualmente, você acabará em um pânico registrado ou em uma entrega final registrada, geralmente no spool de correio local. Isso não significa que a mensagem ainda estará no spool; alguém pode ter lido, ou um trabalho cron ajeitou tudo - mas essa não é a falha do MTA, nem seu problema. Embora tenha sua mensagem, o MTA moverá o céu e a terra para fazer algo com seu e-mail e, se você entender como descobrir, ele informará o que aconteceu.
Comece com os registros.