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:
- Um emitente qualquer envia um e-mail a um Distribuition Group;
- O Distribuition Group possui External Contacts associados como membros;
- O Exchange Online faz o encaminhamento do e-mail ao endereço externo dos External Contacts;
- O MessageLabs (Anti-spam) de saída recusa a mensagem com a seguinte NDR:
| Detalhes da Mensagem Original | ||||||||
|
||||||||
| Detalhes do Erro | ||||||||
|
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’
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.