Detecção de serviço SMTP

Question

Eu tenho algumas perguntas básicas sobre conexões SMTP, particularmente para o Postfix, mas gostaria de receber conselhos para o MS Exchange também:

• Quando uma única retransmissão para um determinado domínio remoto se torna indisponível, com que frequência um postfix mta que está enviando email para esse domínio verifica novamente se o serviço está disponível?
• As conexões com falha "são lembradas" (ou seja, armazenadas em cache)?
• O postfix sempre verifica se os relés de "prioridade mais baixa" estão on-line enquanto um relé de "maior prioridade" está disponível?
• Algum dos ajustes acima no postfix?

Answer 1

Para uma documentação melhor e precisa, sinta-se à vontade para postar a questão na lista de discussão postfix (Wietse Venema é a pessoa ativa nessa lista) ou procure no código fonte do postfix.

Todas as questões acima estão focadas no algoritmo backoff do postfix . Primeiro, vou tentar resolver a questão da destruição do destino

Aqui a parte relevante de man 8 qmgr

STRATEGIES
   The queue manager implements a variety of strategies for either opening
   queue files (input) or for message delivery (output).
   ...
   destination status cache
          The queue manager avoids unnecessary delivery attempts by  main-
          taining  a  short-term,  in-memory  list of unreachable destina-
          tions.

Com base no acima, o postfix de fato tem cache para o host de destino morto. Para controlar esse comportamento, ajuste o qmgr_message_recipient_limit parameter .

qmgr_message_recipient_limit (default: 20000)

The maximal number of recipients held in memory by the Postfix queue manager, and the maximal size of the short-term, in-memory "dead" destination status cache.

Então, quando postfix verificar se o host está vivo? O postfix só tenta se conectar ao host se houver uma mensagem na fila ativa que tenha o destino nela. Além disso, o postfix não verifica ativamente se o host volta vivo.

O Postfix verifica somente o host MX de prioridade mais baixa, se o host principal não estiver disponível ou o código de erro getfix do postfix 4xx do host remoto. Outros MTAs se comportam de maneira diferente quando recebem o código de erro 4xx, já que eles nunca podem tentar conectar-se ao host MX secundário contanto que o MTA possa se conectar ao host primário. Veja: destino postfix cheio / ocupado / erro tente outro destino e O Exchange não envia e-mails para o segundo MX

Com relação ao tempo de repetição da mensagem, o postfix colocará a mensagem na fila deferida se falhar ao entregá-la até bounce_queue_lifetime (para devolução gerada pelo postfix) ou maximal_queue_lifetime (para os outros). Como dito acima, postfix somente reenviar novamente se o qmgr colocar na fila ativa. Aqui, o trecho relevante de documentos postfix sobre o algoritmo de agendamento postfix.

Each deferred queue scan only brings a fraction of the deferred queue back into the active queue for a retry. This is because each message in the deferred queue is assigned a "cool-off" time when it is deferred. This is done by time-warping the modification time of the queue file into the future. The queue file is not eligible for a retry if its modification time is not yet reached.

The "cool-off" time is at least $minimal_backoff_time and at most $maximal_backoff_time. The next retry time is set by doubling the message's age in the queue, and adjusting up or down to lie within the limits. This means that young messages are initially retried more often than old messages.

Então, se você quiser ajustar o tempo de repetição, sinta-se à vontade para jogar com o parâmetro minimal_backoff_time , < href="http://www.postfix.org/postconf.5.html#maximal_backoff_time"> maximal_backoff_time e queue_run_delay .