Um servidor de e-mail de recebimento (o destino final) vê os e-mails entregues diretamente a ele vs. a um revezamento externo que os encaminha para ele?

Question

Digamos que meus usuários tenham contas em algum servidor de correio mail.example.com. Eu tenho atualmente meu registro mx definido como mail.example.com e tudo é bom. Agora, digamos que eu queira que os e-mails sejam entregues inicialmente para um serviço externo (por exemplo, o Postini. No entanto, essa não é uma pergunta específica do postini).

Na situação normal em que meu mx é configurado diretamente para meu servidor de e-mail mail.example.com, o envio de MTAs procurará, é claro, meu MX e enviar para mail.example.com. Na minha nova situação, eu teria meu mx definido como mx.othermailservice.com e os e-mails seriam recebidos lá. O OtherEmailService.com, então, retransmitirá os emails (mantendo o mesmo cabeçalho do caminho de retorno) para mail.example.com. Os e-mails que são recebidos em mail.example.com depois de serem retransmitidos do outro serviço "parecem" diferentes dos e-mails que vão diretamente para ele, como seria o caso em que o mx estava definido como mail.example.com?

    

Answer 1

Existem duas diferenças importantes entre as mensagens roteadas que receberam mensagens recebidas diretamente:

1. O endereço IP da conexão do mailer de entrada não corresponderá às informações do mailer do domínio listado na linha MAIL FROM: na conversa SMTP.
2. O próprio e-mail terá um cabeçalho Received-By: adicional a partir da mala direta de retransmissão.

O primeiro ponto é crítico quando se trata de anti-spam, já que muitas tecnologias AS focam em descartar o e-mail não vindo de onde deveria (ver também, SPF) ou vindo de endereços IP que pareçam engraçados (reputação de IP ). Se você está recebendo retransmissão, seus sistemas AS não devem considerar o endereço IP como parte de sua verificação.

Funciona assim:

1. A mala direta para a Internet em example.client envia uma mensagem para example.yourcorp por meio do registro MX.
2. O servidor listado em seu registro MX, que está fora de sua rede, recebe a conexão de mailer.example.client. Parece que vem de example.client, não cheira excessivamente processado e encaminha para mailer.example.yourcorp.
3. Seu mailer.example.yourcorp recebe uma mensagem recebida de example.client, mas enviada de example.antispam.

Se esta fosse a Internet por volta de 1992, isso não seria um problema. Era um tempo mais confiante naquela época, e nesse caso mailer.example.yourcorp aceitaria alegremente a mensagem e ninguém seria mais sábio.

Spam joga a chave de macaco aqui. Nesse ponto, um serviço anti-spam executado diretamente no mailer.example.yourcorp poderia causar um problema. Uma vez que o registro SPF de example.client (por exemplo) não indica que example.antispam é um mailer autorizado, ele poderia deixar a mensagem no chão para nunca mais ser vista novamente.

Os serviços anti-spam funcionam melhor quando estão sendo executados na mala direta que recebe diretamente mensagens da Internet geral. Isso se deve em grande parte ao fato de que os serviços de reputação de IP têm sido uma das melhores tecnologias anti-spam e, para utilizá-lo, é necessário ver essas conexões TCP. Esconda-se atrás de uma retransmissão de email e você perderá essa vantagem.

O segundo ponto é uma adição por protocolo aos cabeçalhos de correio exigidos pelos padrões SMTP. O cliente nunca deve notar.

    

Answer 2

Depende de como você define "look". Se você está falando se eles parecem diferentes do ponto de vista do cliente, como o outlook, a resposta é não, eles parecem iguais.

A principal coisa que você notará é que os cabeçalhos são diferentes nesses e-mails, obviamente eles estão fluindo através de um novo sistema e você também pode ver novos cabeçalhos de spam. Em alguns casos, os e-mails podem parecer diferentes, pois podem adicionar uma tag na parte inferior dizendo "digitalizado pelo nome do serviço aqui".

Portanto, depende do serviço, mas especificamente com o postini, o usuário final não notará a alteração.