Out-of-Office não envia o e-mail internamente e externamente.

Após uma migração do Exchange 2007 ao Exchange 2016, evidenciamos que o Out-of-Office não respondia os e-mails, sejam internos ou externos. Na realidade o problema havia iniciado com o Exchange 2013 utilizado como ponte para migração do Exchange 2016.

O ponto interessante é que a Policy Tip – aquela que aparece em cima do campo “From” – mostrava a mensagem de Out-Of-Office normalmente. Porém a resposta em si, não era enviada.

Troubleshooting:

Foram realizados alguns troubleshootings a nível de mailbox e transport. A nível de mailbox, abri com o MFCMAPI a mailbox para validar que a regra de Out-of-Office era ativa. Nos hidden contents do Inbox, pude ver que a regra de Out-of-Office era ativa:

4

Posteriormente foi feito um troubleshooting a nível de transporte utilizando o MessageTracking. Evidenciei que os eventos gerados no servidor que o OOF funcionava, eram diferentes dos eventos gerados do servidor problemático. Basicamente os eventos no qual o OOF deve gerar são esses:

error Out-of-Office

  1. Como podemos observar, existem dois eventos de RECEIVE a nível de Mailbox Transport Submission. Isso é correto levando em consideração que ao habilitar o OOF para responder internamente e externamente, são criadas duas regras especificas.

  2. Temos também os eventos de DROP, que fará o descarte sem NDR da mensagem de OOF interna, já que o destinatário é externo.

  3. Como terceiro salto, nos temos o evento de RECEIVE gerado pelo Transport Service. A essa altura, somos seguros que a mensagem então foi gerada, e encaminhada do Mailbox Transport Subimission Service ao Transport Service.

  4. Após isso temos os eventos de AGENTINFO e TRANSFER. Acredito que sejam efetuados a nível de Categorize no Transport Service.

  5. Por último, temos o evento SENDEXTERNAL que representa o enfileiramento da mensagem na Delivery Queue e posterior envio através do Send Connector.

Retornando ao servidor problemático, não haviam praticamente nenhuma LOG de trace. Basicamente os eventos eram gerados apenas até o primeiro passo mencionado (RECEIVE), após isso nada mais era gerado.

A partir disso ficou claro que obviamente o problema era a nível de transport e não de mailbox/store. Já que o e-mail era gerado através do store e recebidos através do Mailbox Transport Submission (eventos de RECEIVE – SOUCE:MAILBOXRULE). Mas em alguma parte do percurso, esse e-mail era era bloqueado.

Com base nessa informação, e embasado em como funciona o mail-flow no Exchange Server 2016, podemos chegar a seguinte conclusão, ou o problema estaria no recebimento por parte do Transport Service,  que utiliza o Default Connector para recebimento dos e-mails provenientes do Mailbox Transport Submission Service, ou o problema estaria no envio do serviço de Mailbox Transport Submission, que no caso faz uma chamada ao Hub Selector para “escolher” o melhor Transport Server a se enviar a mensagem, e a envia utilizando o Intra-Organization Send Connector.

Causa:

Após alguns dias de troubleshooting foi descoberto que o problema era uma falta permissão do grupo ExchangeLegacyInterop no Default Receive Connector. Por padrão a permissão Accept Organization Headers é em Deny – já que esse grupo em teoria nem deveria ser utilizado – mas por alguma razão desconhecida, no passado alguém incluiu o grupo Exchange Servers dentro desse grupo. Portanto em poucas palavras qualquer servidor Exchange era “proibido” de enviar e-mails utilizando o Default Receive Connector.

error Out-of-Office

O grupo ExchangeLegacyInterop hoje em dia não é usado para nada. Nos tempos mais remotos, esse grupo era utilizado para o Exchange 2003 conseguir utilizar o Exchange 2007/2010 como relay. Portanto caso haja um ambiente puro 2013+, esse grupo pode ser deletado.

Resolução:

Optei por simplesmente remover o Deny da permissão Accept Organization Headers e realizar um restart do serviço de Transport Service. Após isso o problema foi sanado, e o OOF voltou a funcionar.

Também seria possível apenas a remoção do grupo Exchange Servers do grupo ExchangeLegacyInterop, o problema seria sanado da mesma forma. Optamos por não realizar dessa forma para saber exatamente se o problema era na permissão de Accept Organization Headers. 

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *