O Relay é um processo natural que pode ser traduzido por "encaminhamento", quando um servidor é utilizado para enviar mensagens para outro dominio ou servidor.

Veja a imagem abaixo e note que o usuário João está tentando enviar um email para a Maria.

Como já sabemos as mensagens não como Instant Messenger que passam diretamente de um computador ao outro. O email precisa ser enviado para um servidor, no exemplo do UOL.com.br, e ele envia ao outro servidor, no exemplo o EMPRESA.com.br. Este processo é chamado de relay, pois o email é de um cliente do UOL direcionado a um cliente de outro dominio e o servidor precisa entregar.

O relay é proibido em duas situações:

1- O destinatário do email não é do servidor que está recebendo. Exemplo: Tentar enviar um email utilizando como SMTP o Yahoo para um endereço do Gmail.
2- O emissor do email é do dominio e não se autenticou. Exemplo: Tentar enviar um email utilizando como SMTP o Yahoo, sendo que meu email é do Yahoo mas eu não passei usuário e senha para o servidor SMTP.

A solução para um problema de relay é muito simples: No seu cliente de email indique o servidor de saida (SMTP) exige autenticação e informe o mesmo usuário e senha que utiliza no POP3.

Mas surgem algumas situações especiais, por exemplo, o problema de relay está acontecendo com o WSUS, System Center ou outros.

Porem, a solução é a mesma. Se o endereço que você indicou como servidor SMTP é, por exemplo, smtp.yahoo.com.br você obrigatoriamente precisa ter um usuário e senha do Yahoo. Não adianta usar um usuário e senha que não seja do mesmo dominio que o SMTP.

Note abaixo a tela de Email Notification do WSUS e veja que o usuario que aparece no nome pode ser outro que não o de autenticação.

Isso acontece porque é necessário para o servidor saber se você realmente está autorizado a enviar emails utilizando seus serviços, e após autenticado vc pode enviar email com qualquer endereço, mesmo que este não exista.

HAAHAA !!!!!  Agora você entendeu porque recebe um monte de email com nomes que não existem (naoresponder@xyz.com.br) e quando tenta responder indica que é inválido e fica a pergunta "se é inválido como que eu recebi?"

Agora você já sabe, o usuário que se autenticou é o joao@xyz.com.br e ele enviou email com o nome naoresponder@xyz.com.br.

COMO TESTAR SE SOU UM RELAY NA INTERNET

Muitas vezes somos um relay e não sabemos, ou seja, qualquer pessoa pode usar nosso servidor para enviar emails para terceiros. Exemplo, o que faz um spammer.

Para testar entre no command prompt e siga a sequencia de comandos:

TELNET <seudominio.com.br> 25  (ou seja, porta 25 de SMTP)
HELO XYZ.COM.BR   (indica o dominio de origem)
MAIL FROM: papainoel@XYZ.com.br  (indica o endereço de origem)
RCPT TO: joao@xyz.com.br  (endereços de destino)

Note que "papainoel" não é usuario do dominio <seudominio.com.br> e o "joao" tambem não, portanto a ação é ilegal, tipica de spammer. É neste momento que deveria retornar a mensagem do titulo "unable to relay".

Para coibir isso procure em seu servidor de email a opção que permite envio de emails (ou relay) apenas para usuários autenticados. Com isso, até aconteceria o que vimos antes, o João mandar email no nome da Maria, mas neste caso no log do servidor indicaria que a conta utilizada foi do João.

Ok, espero ter ajudado e se precisar resolver o problema em seu servidor de email e o que são os problemas de relay. Qualquer dúvida post nos comentário, e se foi util para vc tambem !!! 

Em treinamento a alguns dias me perguntaram sobre instalar o Exchange no Windows 2008 e eu mostrei que tenho dois Exchange 2007 no Windows 2008 sem problemas. Ele disse que na empresa dele não funcionou e o Windows apresentava uma mensagem dizendo que não tem suporte.

A principio não me liguei que o aluno poderia estar se referindo ao R2, porque realmente o Windows 2008 R2 não tem suporte para o Exchange 2007, gostando ou concordando você, é assim!

O bom é que a Microsoft divulgou pelo time do Exchange que está lançando um release, não disse se um R2 ou um SP3, que irá permitir a instalação no Windows 2008 R2.

Segue o link: http://msexchangeteam.com/archive/2009/11/04/453026.aspx

Meu DPM estava funcionando corretamente para os servidores de arquivos, para o Exchange e um SQL. Porem, o nosso CRM estava fora por ser uma maquina já meio sensivel a mudanças, mas virtualizamos para testes e ela não sofreu qualquer problema com o agente do DPM e resolvemos colocá-la no protection group.

Foi ai que começou nosso martitio de feriado de Finados (Home Office, claro):

SINTOMA

O DPM conseguia fazer a réplica de 3 dos 6 bancos de dados e apresentava os 3 com erro "replica is inconsistent", ao que como manda o figurino, tentamos o "perform check".

Os bancos que realizamos o check passaram a ficar como realizando o check e os outros que estavam prontos começavam a dar erro. Fora isso, o System State não rodava de jeito nenhum.

É claro que o alerta gerado tinha detalhes muito bons para resolver o problema do tipo "veja se o servidor está ligado, a placa de rede conectada, serviço em execução..."

CAUSA

Ao instalar o Hotfix KB940349 que é obrigatório no Windows 2003 porque atualiza o Shadow Copy, os agentes VSS ficaram corrompidos.

Ao executar o comando vssadmin list writers notei que ele não tornava resposta, cheguei a deixar por 2 horas em espera e nada. Ao tentar ir nas propriedades e para ativar o shadow copy este aparecia como desabilitado, apesar de ter acusar quase 1 GB de ocupação e não era possivel ativar.

SOLUÇÃO

Reiniciei o servidor CRM em modo de segurança e executei o vssadmin delete shadows.

Reiniciei novamente em modo normal e nas propriedades do computador reativei o shadow copy normalmente.

Maravilha, bastou ir no DPM e executar a função "perform check" e pronto, tudo funcionando desde então !!!!