NDR recebida pelo Exchange Online: 550 5.0.350 Remote server returned an error -> 553 you are trying to use me [server-15.tower-56.messagelabs;.com] as a relay, but I have not been configured to let;you

Após migrar o fluxo de entrada de e-mails do Exchange 2010 ao Exchange Online, iniciou-se um problema com contatos externos com a NDR 550 5.0.350. Imagine a seguinte situação:

  1. Um emitente qualquer envia um e-mail a um Distribuition Group;
  2. O Distribuition Group possui External Contacts associados como membros;
  3. O Exchange Online faz o encaminhamento do e-mail ao endereço externo dos External Contacts;
  4. O MessageLabs (Anti-spam) de saída recusa a mensagem com a seguinte NDR:

NDR 550 5.0.350

Detalhes da Mensagem Original
Data de Criação: 06/12/2017 15:24:38
Endereço do Remetente: denis.signorelli09@outlook.com
Endereço do Destinatário: dsignorelli@contoso.com
Assunto: test SMTP 16:24
Detalhes do Erro
Erro relatado: 550 5.0.350 Remote server returned an error -> 553 you are trying to use me [server-15.tower-56.messagelabs;.com] as a relay, but I have not been configured to let;you [213.199.154.115, mail-am5eur03lp0115.outbound.prote;ction.outlook.com] do this. Please visit;www.symanteccloud.com/troubleshooting for more details;about this error message and instructions to resolve;this issue. (#5.7.1)
DSN gerado por: AM4PR03MB1410.eurprd03.prod.outlook.com
Servidor remoto: server-15.tower-56.messagelabs.com

Causa:

Como a própria NDR informa, o MessageLabs regeitou a mensagem informando que o domínio especifico do emitente não é autorizado a fazer relay. Em pratica o MessageLabs está certo. Entretanto porque antes com o Exchange 2010 funcionava e agora com o Exchange Online não funciona mais ?

Pois bem, analisei algumas logs e headers de e-mails enviados de fora a um grupo de distribuição e depois encaminhado a um contato externo. Notei que o valor de return-path nesse caso é convertido ao nome do grupo de distribuição.

Exemplo: Eu denis.signorelli@hotmail.com envio um e-mail ao grupo de distribuição grupo@contoso.com , que consequentemente possui um membro External Contact com o e-mail fulano@dominio.com

O e-mail ao ser expandido pelo grupo@contoso.com, muda automaticamente o return-path de denis.signorelli@hotmail.com a grupo@contoso.com . O campo FROM no header se mantem, portanto essa é uma diferença de comportamento entre o Exchange 2010 e Exchange Online – ou 2016, que é a mesma engine.

Abri um chamado com a Symantec para verificar se isso poderia ser a real causa do bloqueio das mensagem, pelo fato de o Exchange Online não reescrever o return-path e utilizar o mesmo do emitente original. Fui informado que talvez sim, mas a causa raiz ainda sim pode não ser essa.

A Symantec me informou que provavelmente o que ocorria é que no momento do “Message Envelope” do Exchange Online ao MessageLabs. O Exchange estava utilizando o campo “MAIL FROM:” com o endereço original do emitente ao invés de utilizar o endereço do grupo – por exemplo “MAIL FROM:grupo@contoso.com”.

Porém eu não consegui uma resposta clara nas documentações da Microsoft se realmente o Exchange Online se comporta dessa maneira no “Message Envelope” de casos como esse. Na minha opinião sim, o Exchange Online utiliza o e-mail do emitente para fazer o “Message Envelope”. Por isso o Return-Path não é consequentemente o reescrito. Mas certeza mesmo eu haveria apenas consultando as verbose logs de Outbound Connector do Exchange Online, mas infelizmente isso não acessível a nós, talvez apenas a Microsoft.

Solução:

Nesse caso temos três soluções, sendo as duas primeiras meio “radicais”, e a ultima a que mais me pareceu viável.

  • Realizar um By-pass do MessageLabs desabilitando o Outbound Connector. O problema dessa solução é que não faz sentido pagar por um antispam e usá-lo somente pela metade.

 

  • Manter o Exchange 2010 na organização como ponto de entrada de fluxo dos e-mails. O problema dessa solução é que muitas vezes já estamos indo ao Office 365 pois queremos ter o mínimo possível de coisas On-Premises. Portanto deixar o Exchange 2010 no meu entendimento era um retrocesso, após já haver migrado tudo ao Exchange 2016 e Exchange Online.

 

  • A terceira e mais viável solução no meu entendimento foi realizar um by-pass do MessageLabs somente para situações como essa, em que existe um External Contact no grupo. Para isso eu realizei o seguinte procedimento:

1) Crie um Outbound Connector com a seguinte configuração:

From: Office 365

To: Organization Partner

When to use the connector: Use only when I have a transport rule set up that redirects messages to this connector.

Routing method: Use the MX record associated with the partner’s domain.

2) Crie uma Transport Rule com as seguintes características:

If the message: Is sent to ‘Outside the organization’ and Is received from ‘Outside the organization’

Do the following: Route the message using the connector named ‘Outbound to Internet – External Contacs’ and set message header ‘X-BypassOutboundRule’ with the value ‘This Message was Bypassed from MessageLabs by the “Outbound to Internet – External Contacs” Connector’

4

Logo após criação, espere em torno de meia hora e comece a realizar os devidos testes. Conforme mencionado no procedimento, os e-mails que sofrerem by-pass através do novo conector, iram automaticamente escrever uma mensagem no header. Dessa forma fica mais fácil de fazer o troubleshooting.

Deixe uma resposta

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