Alguns dos e-mails que passam pelo meu servidor são encaminhados para contas externas.
Infelizmente, meu servidor SMTP upstream é muito exigente com spam - e rejeita algumas das mensagens legítimas como tal. Quando isso acontece com o correio encaminhado, recebo as devoluções (como o postmaster) - não os originadores.
Entendo que isso ocorre porque o sendmail enfileira as mensagens localmente, desconecta-se da retransmissão e só então prossegue para encaminhá-las. Se o encaminhamento adicional for interrompido por qualquer motivo - como porque o próximo relé identifica erroneamente a mensagem como spam - meu sendmail é deixado para reter os pedaços.
As coisas podem ser configuradas para que o encaminhamento comece imediatamente (assim que o destino do encaminhamento for determinado)? O status - sucesso ou falha - pode então ser comunicado diretamente ao relé anterior ainda na linha ...
Se o sendmail não puder fazer isso, algum outro MTA pode? Obrigado!
Não, não é possível, pois não é implementado com nenhum software SMTP amplamente difundido; você teria que programar seu próprio servidor SMTP que suportasse esse tipo de comportamento, o que estaria fora do escopo do Serverfault . Nesta resposta explico porque todos os MTAs implementaram o protocolo SMTP de forma muito semelhante, usando queue, e como essa é a melhor maneira de cumprir todos os requisitos do protocolo.
Um agente de transporte de correio MTA sempre nega uma mensagem ou a aceita e a enfileira, com base em suas próprias configurações. Em seguida, é retransmitido ou entregue da fila.
Isso é porque
pode haver erros permanentes e temporários. Se o MTA não conseguir conectar o nexthop imediato, ele tentará novamente mais tarde e retornará apenas se o atraso atingir o limite definido. Também não pode esperar que outro MTA responda antes de fechar a conexão, pois pode ter outras mensagens para entregar primeiro.
pode haver vários destinatários. Enquanto um cliente pode simplesmente listar todos os destinatários de uma vez com
RCPT TOcomandos, a mensagem pode finalmente ser entregue a vários outros servidores, dos quais alguns podem estar disponíveis agora e outros mais tarde. Além disso, o MTA não pode abrir todas essas conexões de uma vez durante a conexão inicial e aguardar suas respostas. Não há nenhuma razão prática para ter um fluxo de trabalho totalmente diferente para mensagens com um único destinatário.deve sempre ficar claro qual MTA atualmente tem a responsabilidade de entregar a mensagem. (Isso foi explicado por exemplos na resposta do MadHatter.)
É assim que o SMTP foi projetado. Em vez de requisitos sintáticos para os comandos de conexão, isso leva a arquiteturas muito semelhantes ; Sendmail , Postfix e até mesmo o MS Exchange possuem componentes separados para enviar e receber e-mails.
O requisito ainda vem da especificação SMTP; RFC 5321 2.1 na estrutura básica do modelo SMTP:
E um pouco mais:
Acho a resposta da Esa excelente, mas vou discordar de algumas. Acho que o que você quer é possível, mas é uma má ideia, e não vai te ajudar. Como ele diz, RFC5321 s2.1 observa que
No caso em que o servidor B recebe uma mensagem do servidor A e a entrega ao servidor C, não vejo que isso impeça B de esperar para confirmar o recebimento de A até que tenha confirmação de recebimento de C - que é o que você está pedindo. Mas o problema é que entre dois servidores
250 OKé atômico (ou o receptor aceitou, e então é responsável pela entrega, ou não, e então o remetente continua responsável), enquanto entre três não é.Considere o caso em que o cliente A é desconectado involuntariamente depois de ter enviado o e-mail, mas antes de receber o
250 OK, enquanto B o está entregando para C. C confirma o recebimento de B com seu250 OK, então B sabe que C o tem. Mas A não, então A ainda deve ser responsável e deve continuar a entregar para B. Se houver algum problema de comunicação sistemático entre A e B (por exemplo, um daqueles firewalls adoráveis que pensam que é seu trabalho mexer com o conteúdo de conversas SMTP), isso pode resultar na entrega de um número muito grande de cópias da mesma mensagem.Além disso, o sendmail já faz o que você acha que não faz: no caso de falha na entrega para C, ele tentará passar a responsabilidade de volta para A. Isso geralmente só falha onde A é malicioso, e também está no envelope-From (a quem essa notificação deve ser feita) ou não executa nenhum servidor de correio. Nesses casos, a correspondência deve ser entregue ao postmaster de B, pois B é responsável pela entrega (tendo dito
250 OKa A, mas não a recebeu de C), não pode entregar a C (está tentado e obteve uma falha permanente 5xx) e não pode devolver para A (porque A tornou isso impossível), então não tem mais ninguém para dar. Aqui está um exemplo que recebi esta manhã:Observe como o e-mail original pretende vir de um endereço aol.com. Como, então, não estou tentando entregar o relatório de falha de volta para eles? Porque eles mentiram em sua transação SMTP original:
É minha culpa que eu ainda não configurei o SPF para esse meu domínio específico (
stphilipschurch.org.uk), mas como não o fiz, nada me impede de aceitar essa mentira - e então fico preso com uma mensagem não entregue que não pode ser retornada ao remetente, pois o remetente é malicioso e desinteressado (estar conectado através de um ISP no Azerbaijão).tl; dr : o sendmail já faz o que você está pedindo, quando pode. O que você quer fazer não ajudará quando não puder, e criará problemas. Não faça isso.