Estudo de caso - envio por SMTP autenticado e o erro #550 5.7.1 Access Denied ##


A pouco tempo enfrentei um problema relacionado a envio de e-mails por um cliente, e isso causou realmente um problema sério, pois a área de compras, pedidos e áreas relacionadas pararam de enviar suas solicitações.

A empresa possui um servidor Exchange para enviar e receber e-mail, porém o serviço de SMTP é disparado pelo provedor genérico (uso a palavra genérico para não citar nome de empresa).

Um belo dia o provedor barrou a autenticação externa, e o resultado prático é que recebíamos os e-mails porém não podíamos enviar mensagens. 

Quando a autenticação é feita por um servidor interno como um AD, por exemplo, é possível autenticar com uma conta e enviar por outra, então a prática de disparo esta sendo bloqueada. A saída então foi de contratar um servidor SMTP autenticado por outra empresa.

É possível identificar esse bloqueio pela mensagem de erro que é retornada ao usuário. Procure pela linha server.correio.bizancio #550 5.7.1 Access Denied ## onde nesse caso use o nome server.correio.bizancio apenas como exemplo. Cada provedor tem seu nome de servidor.

O Exchange dispara as mensagens via SMTP, por um link dedicado de IP fixo para um servidor SMTP autenticado e recebe o serviço de POP pelo mesmo link diretamente.

A zona de DNS ainda esta com o provedor genérico, então é necessário criar a entrada SMTP também nesse provedor. Lembrando que deve ser criado uma entrada do tipo CNAME.

Depois de muita encrenca e problemas de envio e recebimento, conseguimos identificar os seguintes sintomas dessa mudança brusca:
  • Os destinatários recebem em lixo eletrônico durante um período, sendo necessário que o provedor de destino adicione o domínio de emissão em remetentes confiáveis;
  • A propagação de Zona de DNS adicional leva um determinado tempo de propagação;
  • Verifique se o reverso esta cadastrado corretamente, pois isso influencia no recebimento de e-mail;
  • Não esqueça de validar o incude nas linhas de SPF;

Esse tipo de ação foi emergencial e nunca deve ser feita qualquer mudança em zonas de DNS ou MX durante a semana ou expediente de trabalho, pois a propagação pode ser lenta e demorada. É altamente recomendável que isso seja feito aos finais de semana ou na sexta-feira após o expediente de trabalho, lembrando que isso tem uma variação grande de empresa para empresa.

Lidar com e-mail de uma empresa nos dias atuais é um verdadeiro ninho de marimbondos e pode fazer certas cabeças rolarem no departamento de TI. Ajuda muito ter conhecimento técnico, contatos em provedores e ações rápidas, já que muitos SLA´s não contemplam a parte de disparo autenticado por AD interno do cliente.

Quando for administrar a rede de alguém, faça um levantamento por etapas e crie uma análise de vulnerabilidade, ou você terá problemas sérios.

Se a realidade da empresa exigir algo específico, não tente criar formulas mágicas, acione especialistas e se necessário contrate parceiros de negócio confiáveis. Lembre que por trás do que é pago, existe o valor agregado de tempo de atendimento, solução, bkp e muitas outras ações que muitas vezes não estão disponíveis em nossa realidade.

Espero ter ajudado e se você gostou faz um UP no post, mas se você tem outras ideias, vamos discutir e chegar a um novo consenso. Vai que a sua ideia é melhor que a minha rs... com certeza vou de agradecer, pois fiz o que sabia e corrigi o problema, mas existe sempre uma forma mais segura e mais interessante de fazer.

Bom, vou estudar mais o cenário e corrigir os problemas que encontrar e qualquer novidade, faço um novo post.

Grande abraço e sucesso.


Postar um comentário

Comente sem faltar com respeito - ;-)

Postagem Anterior Próxima Postagem