O e-mail do sendmail pode ser enviado imediatamente em vez de enfileirar?

Question

Alguns dos e-mails que passam pelo meu servidor são encaminhados para contas externas.

Infelizmente, meu servidor SMTP upstream é muito exigente quanto a spam - e rejeita algumas das mensagens legítimas como tal. Quando isso acontece com o e-mail encaminhado, recebo os bounces (como o postmaster) - não os originadores.

Eu entendo que isso acontece porque o sendmail enfileira as mensagens localmente, desconecta-se do relay e só então continua a encaminhá-las ainda mais. Se o encaminhamento for interrompido por algum motivo - por exemplo, porque o próximo relé identifica incorretamente a mensagem como spam - meu sendmail é deixado para guardar as peças.

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 pode fazer isso, pode qualquer outro MTA? Obrigado!

    

Answer 1

Não, não é possível, pois não é implementado com qualquer software SMTP de grande difusão; você teria que programar seu próprio servidor SMTP que suporta esse tipo de comportamento, que estaria fora do escopo no Serverfault . Nessa resposta, explico por que todos os MTAs implementaram o protocolo SMTP de maneira muito semelhante, usando a fila e como essa é a melhor maneira de cumprir todos os requisitos do protocolo.

Um agente de transporte de email MTA sempre nega uma mensagem ou a aceita e a enfileira, com base em suas próprias configurações. Então, é retransmitido ou entregue da fila.

Isso é porque

• pode haver erros permanentes e temporários. Se o MTA não puder conectar o nexthop imediatamente, ele tentará novamente mais tarde e só retornará se o atraso atingir o limite definido. Também não pode esperar por outro MTA para responder 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 comandos RCPT TO , a mensagem pode ser finalmente entregue a vários outros servidores, alguns dos quais podem estar disponíveis agora e alguns mais tarde. Além disso, o MTA não pode abrir todas essas conexões de uma vez durante a conexão inicial e esperar por 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.

• Sempre deve estar claro qual MTA atualmente tem a responsabilidade de entregar a mensagem. (Isso foi explicado por exemplos na resposta de MadHatter.)

É assim que o SMTP foi projetado. Em vez de exigência sintática para os comandos de conexão, isso leva a arquiteturas muito semelhantes ; Sendmail , Postfix e até mesmo MS Exchange possui componentes separados para enviar e receber mensagens.

1. O componente do servidor SMTP recebe e-mails e os adiciona à fila.
2. Em seguida, o cliente SMTP separado tenta enviá-lo para outros MTAs ou, se um destinatário for local, a mensagem pode ser salva em um arquivo ou passada para um agente de entrega de e-mail MDA, por exemplo. Procmail.

O requisito ainda vem da especificação do SMTP; RFC 5321 2.1 na estrutura básica do modelo SMTP:

Fully-capable SMTP implementations, including the relays used by these less capable ones, and their destinations, are expected to support all of the queuing, retrying, and alternate address functions discussed in this specification. In many situations and configurations, the less-capable clients discussed above SHOULD be using the message submission protocol (RFC 4409) rather than SMTP.

E um pouco mais:

In other words, message transfer can occur in a single connection between the original SMTP-sender and the final SMTP-recipient, or can occur in a series of hops through intermediary systems. In either case, once the server has issued a success response at the end of the mail data, a formal handoff of responsibility for the message occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so (see Sections 6.1, 6.2, and 7.8).

    

Answer 2

Eu acho que a resposta da Esa é excelente, mas vou discordar de algumas delas. Eu acho que o que você quer é possível, mas é uma má ideia, e isso não vai te ajudar. Como ele diz, o RFC5321 s2.1 observa que

once the server has issued a success response at the end of the mail data, a formal handoff of responsibility for the message occurs: the protocol requires that a server MUST accept responsibility for either delivering the message or properly reporting the failure to do so

No caso em que o servidor B recebe uma mensagem do servidor A e a entrega no servidor C, não vejo que esta barra B esteja esperando para confirmar o recebimento para A até que tenha recebido a 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 é responsável pela entrega, ou não, e assim o remetente continua responsável), enquanto entre três não é.

Considere o caso em que o cliente A é desconectado acidentalmente após enviar o email, mas antes de ter o 250 OK , enquanto B o entrega para C. C então confirma o recebimento de B com seu 250 OK , portanto B sabe que C tem isso. Mas A não, então A ainda deve ser responsável, e deve continuar a reenviar para B. Se houver algum problema de comunicação sistemática entre A e B (por exemplo, um desses firewalls adoráveis que acham que é seu trabalho mexer com o conteúdo de conversas SMTP), isso pode resultar em um grande número de cópias da mesma mensagem sendo entregue.

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 o dinheiro de volta para A. Isso geralmente só falha onde A é malicioso, e ou está no envelope-From (para quem tal notificação deve ser feita) ou não executa um servidor de e-mail. Nesses casos, o e-mail deve ser entregue ao postmaster de B, pois B é responsável pela entrega (tendo dito 250 OK para A, mas não tinha de C), não pode entregar para C (é tentado e tem uma falha permanente 5xx) e não pode voltar para A (porque A tornou isso impossível) então não tem mais ninguém para dar a ele. Aqui está um exemplo que recebi esta manhã:

Date: Tue, 8 Aug 2017 02:53:55 +0100
From: Mail Delivery Subsystem <[email protected]>
To: [email protected]
Subject: Returned mail: see transcript for details
Parts/Attachments:
   1   Shown     17 lines  Text
   2   Shown    407 bytes  Message, "Delivery Status"
   3   Shown     15 KB     Message
   3.1           10 KB     Application
----------------------------------------

The original message was received at Tue, 8 Aug 2017 02:53:53 +0100
from localhost [IPv6:::1]

   ----- The following addresses had permanent fatal errors -----
<[email protected]>
    (reason: 550-5.7.1 Unauthenticated email from aol.com is not accepted due to domain's)

   ----- Transcript of session follows -----
... while talking to gmail-smtp-in.l.google.com.:
>>> DATA
<<< 550-5.7.1 Unauthenticated email from aol.com is not accepted due to domain's
<<< 550-5.7.1 DMARC policy. Please contact the administrator of aol.com domain if
<<< 550-5.7.1 this was a legitimate mail. Please visit
<<< 550-5.7.1  https://support.google.com/mail/answer/2451690 to learn about the
<<< 550 5.7.1 DMARC initiative. 53si155585wrc.260 - gsmtp
554 5.0.0 Service unavailable

    [ Part 2: "Delivery Status" ]

Reporting-MTA: dns; lory.teaparty.net
Received-From-MTA: DNS; localhost
Arrival-Date: Tue, 8 Aug 2017 02:53:53 +0100

Final-Recipient: RFC822; [email protected]
Action: failed
Status: 5.7.1
Remote-MTA: DNS; gmail-smtp-in.l.google.com
Diagnostic-Code: SMTP; 550-5.7.1 Unauthenticated email from aol.com is not accepted due to domain's
Last-Attempt-Date: Tue, 8 Aug 2017 02:53:55 +0100

    [ Part 3: "Included Message" ]

Date: Tue, 08 Aug 2017 01:53:46 -0000
From: [email protected]
To: [email protected]
[...]

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 falhas de volta para eles? Porque eles mentiram em sua transação SMTP original:

Aug  8 02:53:51 lory sendmail[9457]: v781rmjA009457: from=<[email protected]>, size=14095, class=0, nrcpts=1, msgid=<[email protected]>, proto=SMTP, daemon=MTA-v6, relay=[37.114.157.178]

É minha culpa que eu ainda não configurei o SPF para esse domínio em particular ( stphilipschurch.org.uk ), mas como não o fiz, nada me impede de aceitar essa mentira - e então eu estou presa a um mensagem não entregue que não pode ser devolvida 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 o ajudará quando não puder, e criará problemas. Não faça isso.