Estou muito curioso sobre isso. A questão (highlighed em negrito):
Alguém pode nomear ONE GOAS REASON para ter seu servidor de e-mail permanentemente configurado para falha automática / falha imediata nos códigos 4xx?
Porque, francamente, parece que as "suas" configurações estão fora da caixa. O SMTP não é o Instant Messaging. Pare de tratá-lo como o IRC ou o Jabber ou o MSN ou insira a tecnologia do IM aqui . Eu não sei o que possui pessoas para ter a mentalidade de "entrega imediata ou falha" com configurações de SMTP, mas eles precisam parar de fazer isso. Simplesmente quebra as coisas. A cada dois ou três anos, tropeço nisso. Alguém, em algum lugar, decidiu em sua infinita sabedoria que os códigos 4xx são falhas imediatas e, de repente, seu código é em vez de "oh, ele tentará novamente a entrega em apenas 30 minutos". Espanta-me como de repente se torna "meu" problema que uma mensagem não passará, porque alguém configurou mal o "seu" serviço SMTP.
SE houver um motivo legítimo para que seu servidor seja configurado permanentemente dessa maneira, a primeira boa resposta receberá o cheque.
SE não houver nenhuma boa razão (e eu suspeito que não há), então a primeira resposta de bom som, se ainda com falha lógica, receberá o cheque.
Eu configurei uma vez dessa forma porque o proprietário queria saber quando os e-mails seriam atrasados e, em caso afirmativo, ele queria alterar o texto do e-mail. Isso foi para uma negociação frim para que eu possa entender a necessidade de pontualidade. Além de algo assim, não posso imaginar por que (e eu pensei que era uma vez em uma configuração de lua azul)
Do RFC:
4.X.X Persistent Transient Failure
A persistent transient failure is one in which the message as
sent is valid, but some temporary event prevents the successful
sending of the message. Sending in the future may be successful.
Está bem claro que o 4xx só deve ser enviado em resposta a um problema temporário (transiente sendo mau texto). Segue-se, portanto, que não há razão justificável para tratá-lo como um erro imediato . Deve ser respondido como sendo tentativas de rotina.
Com isso dito, o uso excessivo de negrito e itálico sugere que você leve esse assunto não apenas a sério, mas pessoalmente. O melhor que posso sugerir é apenas relaxar e não ficar tão perturbado com a idiotice de outra pessoa.
Quando alguém reclama, apenas aponte essa parte do RFC (deixando de fora o fato de que um RFC não é um padrão) e lembre-os de que você não tem controle sobre como os outros configuram seus sistemas.
Pensando nisso, posso pensar que pode haver algum tipo de ataque DoS se for iniciado de dentro, onde o cliente envia uma porcaria de carga de e-mails para servidores smtp inválidos conhecidos. Isso faria com que o servidor de e-mail começasse a colocar mais carga em si mesmo enquanto tentava reenviá-lo.
Eu não chamaria isso de uma boa razão, mas talvez seja pelo menos "bom som"? : -)
Talvez outro motivo possa ser "Se não funcionou na primeira vez, provavelmente não funcionará, então vamos deixar o usuário saber imediatamente. E eu não sei como alertá-lo de que isso vai continue tentando ". Aquilo soa ainda mais idiota para mim ...
Tags smtp message-queuing