Explica-me um cena sff.
Qd o servidor de envio está a enviar um e-mail existente para um servidor real ( o teu por ex) , os dados vão para algum lado certo? Isto é, os dados são enviados e não retorna nenhum menssagem de erro.
Ora se isto é assim, eu posso assumir que um mail enviado para o teu servidor ( sem qq pedido de aviso de recepção), que não retorne nenhuma mensagem de erro, chegou mesmo ao teu servidor.
Ou não?
Podes assumir que sim.
Ou seja, um servidor bem configurado deve dar uma mensagem de erro SMTP
caso a mensagem não seja aceite. Logo, não dando erro, pode assumir-se que
a mensagem foi aceite.
Mas...
Há quem configure os servidores para SILENT REJECT. Ou seja, rejeição silenciosa,
que normalmente é usada quando o servidor acha que a mensagem é SPAM. Mas
isto é um funcionamento errado segundo o RFC.
De qualquer modo, o DSN (Delivery Status Notification) não tem nada a ver com
isto. Porque a mensagem de erro de rejeição é uma resposta ao servidor que está
em contacto com o nosso, e que ocorre durante o protocolo de comunicação entre
ambos (SMTP). Já o DSN é uma mensagem de e-mail que é enviada pelo nosso
servidor para o remetente do e-mail que pediu esse DSN.
A diferença pode parecer insignificante, mas é enorme.
No caso do erro durante a comunicação SMTP, é o servidor que iniciou a comunicação
que é informado do erro.
No caso do DSN é o remetente. Como o endereço do remetente pode ser facilmente
falsificado, o DSN pode estar a ser entregue a uma vítima inocente. Ou seja, poderemos
estar a ser usados para propagar SPAM, ou para fazer DoS.
Bounce message - Wikipedia, the free encyclopedia
Why you shouldn't bounce spam and viruses
Portanto, não existe nenhum problema em rejeitar mensagens sem ser silenciosamente.
Mas há problemas em rejeitar silenciosamente, e ainda mais problemas em fazer
bounce (e delivery e read receipts).