COMO IDENTIFICAR SPAM - PART 4

DETALHES TÉCNICOS - COLETANDO INFORMAÇÔES DO CABEÇALHO

Vimos na parte 3 as sintaxes de HELO e MAIL FROM. Esses verbos somente serão vistos com o uso de alguma ferramenta especial, por exemplo TCPDUMP, e se ela operar no sistema que recebe ou envia a mensagem.

E quando a mensagem está no sistema receptor e foi, ou está prestes a ser entregue à caixa postal do destinatário? Onde buscar indícios de spam ou malicia?

Se a mensagem já está na caixa postal do destinatário, e ele já a abaixou para o seu computador, a solução é observá-la por inteiro. A maioria dos visualizadores de mensagens possuem recursos para mostrar o cabeçalho completo e o corpo.

Nos visualizadores derivados do Netscape-Mail, Mozilla-Mail e Mozilla-Thunderbird, basta pressionar a sequência [CTRL][U] (teclas CRTL esquerda ou direita do teclado e a tecla da letra U). Primeiro aperte a tecla CTRL e mantendo-a pressionada, pressione a tecla U. Uma nova janela mostrará toda a mensagem com o cabeçalho completo e corpo.

As numerações das linhas não são apresentadas no visualizador de E-mail. Elas foram incluidas para facilitar a localização das informações.

Observar que a visualização do cabeçalho completo também mostra todo o caminho que a mensagem percorreu mas, infelizmente, tal informação não é confiável.

LINHA 01

O e-mail informado pelo cabeçalho Return-Path: é uma cópia do e-mail informado no ENVELOPE "MAIL FROM", ou seja do remetente.

Cabe lembrar que as RFCs permitem mais de um remetente. Neste caso, este campo registrará, apenas, o primeiro deles.

LINHAS 02 a 03

O campo 'X-Original-To:' (linha 02) informa o endereço definido pelo envelope RCPT TO:, ou seja é o email informado do destinatário.

Um email de destinatário pode ser um "apelido" (alias) para um e-mail real, que é informado na linha 03, pelo campo 'Delivered-To:'

LINHAS 04 a 06

O campo 'Received:' é extenso e traz várias informações. A RFC define que o valor deste campo deve ser separado em linhas, obedecendo a ordem genérica definida a seguir. Os termos em negrito são preenchidos com as informações coletadas durante a sessão SMTP.

Received: from HELO (IP-REV [IP#])
      by MTA-RX (MTA-NAME) with PROTOCOL id ID#
      for <RPCT TO>; DATA-RFC822-LOCAL

Comparando a sintaxe genérica com as linhas 04 a 06, obtem-se:

HELO = if01-mail-sr09-mia.mta.lua.com

É o nome informado no anúncio de HELO.

IP-REV = if01-mail-sr09-mia.mta.lua.com

É o nome IP obtido a partir da Tradução Pseudo-reversa.

IP# = 218.84.243.26

É o endereço IP copiado a partir da conexão entre os sistemas.

MTA-RX = guri.no-ip.org

É o primeiro nome-IP do sistema que recebe a mensagem.

MTA-NAME = Postfix

É o nome da aplicação MTA. Ou seja, é a aplicação/programa executada/o no sistema MTA-RX que cuidará do envio da mensagem para o destinatário.

PROTOCOL = ESMTP

As aplicações MTA-NAME podem implementar extensões do protocolo SMTP, onde são possíveis autenticações, envio de diversos tipos de anexos, confirmações de recebimento, etc. O sistema emissor da mensagem tenta negociar tais recursos, caso os possua. Se a negociação tem sucesso opta-se pelo protocolo extendido, identificado por ESMTP.

ID# = BC708C65

É um código de identificação da tarefa a ser executada pela MTA-NAME, no sistema MTA-RX, para enviar a mensagem ao destinatário.

RPCT TO = ugarno@guri.no-ip.org

É o E-mail do destinatário infromado no envelope da mensagem, verbo 'RCPT TO'.

DATA-RFC822-LOCAL = Mon, 4 Feb 2013 09:07:14 -0200 (BRST)

É o registro da data efetiva de recebimento da mensagem. Esta informação é registrada pelo sistema recebeu a mensagem.

LINHAS 07 a 09

As linhas 07 a 09 também se referem ao registro de um sistema por onde aquela mensagem passou. Deve-se interpretá-la da mesma forma que as linhas 04 a 06.

Observar que o valor do campo genérico HELO indica que há algum outro sistema intermediário.

Também pode-se observar que não há tradução reversa para o IP 10.235.200.47 pois o campo IP-REV genérico tem o valor unknown.

Comparando as datas entre destas linhas com aquela definida nas linhas 04-09, observa-se um atraso de 14 segundos.

09:07:14 -0200 (BRST) = 11:07:04 +0000 (UTC) + 14seg.

A simples converter '-0200 BRST' para '+0000 UTC'.

A sintaxe dos tempos é +/-HHMM (Hora|Minutos).

Então, -0200 representa 2 horas antes de UTC. OK?

Um atarso de 14 minutos é "aceitável" se, e somente se, o relógio do sistema MTA-MX não for confiável.

LINHAS 10 a 13

Estas linhas seguem 'quase' a mesma sintaxe do formato genérico, exceto pela informação adicional:

(authenticated user arnutic@lua.com.br)

Ela informa que o usuário 'arnutic', remetente da mensagem, foi autenticado pelo sistema MTA-MX (155.tpn.lua.com).

Para prevenir o uso indevido de seus serviços de correio eletronico, os provedores de acesso condicionam aquele uso perante um autenticação do cliente.

Cabe também observar que o nome de anuncio de HELO do cliente não está devidamente configurado, pois SERVIDOR não é um nome completo e válido para a Internet.

LINHA 14

A linha informa o campo 'Message-ID:' com o valor de identificação única mensagem DBC650BB289342BF89AF607FB4952CAD@SERVIDOR.

Apesar de SERVIDOR não ser um nome válido, o campo confirma que a mesagem foi criada e enviada a partir daquele sistema.

LINHA 15

Conforme visto anteriormente, o email do campo 'To:' retrata o real destinatário da mensagem.

As RFCs citam que a informação pode ser alterada por um sistema receptor (ou intermediário) quando o número de destinatários é uma lista oculta ou muito extensa. Neste caso, o campo assumirá o valor 'Undisclosed-Recipients".

O campo SEMPRE deve existir em outras condições. A sua ausência é um indício de fraude ou de sigilo "injustificável".

LINHA 17

O campo 'References:' do cabeçalho justifica o motivo de contato. O valor E1U1uuG-0006MT-6S@linux.tserverhosting.com indica que houve um contato prévio controlado que ocorreu no sistema linux.tserverhosting.com.

Posso afirmar que o contato existiu através de um formulário Web.

LINHA 18

O campo 'Subject:' foi definido pelo formulário de contato confirmado anteriormente.

os spammers, algumas vezes, usam do recurso MIME para ocultar evitar que o assunto seja facilmente detectado por alguma regra de bloqueio.

O formato MIME, codificaria aquela mesma frase na forma:

?BASE64=UmU6X09y52FtZW50b19lbnZpYWRvX3BlbG9fc2l0ZSAgVWxpX0d1aWRlcw==

LINHA 19

O campo Date regsitra a data que a mensagem foi criada. Neste caso, é possível concluir que a a mensagem foi criada e enviada imediatamente.

Na próxima parte mostra-se uma mensagem spam.