Por que um endereço MAIL FROM vazio pode ser enviado por email?


9

Estamos usando o sistema Smarter Mail. Recentemente, descobrimos que o hacker havia hackeado algumas contas de usuário e enviado muitos spams. Temos um firewall para limitar o remetente, mas para o email a seguir, o firewall não pôde fazer isso por causa do endereço FROM vazio. Por que um endereço FROM vazio é considerado OK? Na verdade, no nosso MTA (surgemail), podemos ver o remetente no cabeçalho do email. Qualquer ideia?

11:17:06 [xx.xx.xx.xx][15459629] rsp: 220 mail30.server.com
11:17:06 [xx.xx.xx.xx][15459629] connected at 6/16/2010 11:17:06 AM
11:17:06 [xx.xx.xx.xx][15459629] cmd: EHLO ulix.geo.auth.gr
11:17:06 [xx.xx.xx.xx][15459629] rsp: 250-mail30.server.com Hello [xx.xx.xx.xx] 250-SIZE 31457280 250-AUTH LOGIN CRAM-MD5 250 OK
11:17:06 [xx.xx.xx.xx][15459629] cmd: AUTH LOGIN
11:17:06 [xx.xx.xx.xx][15459629] rsp: 334 VXNlcm5hbWU6
11:17:07 [xx.xx.xx.xx][15459629] rsp: 334 UGFzc3dvcmQ6
11:17:07 [xx.xx.xx.xx][15459629] rsp: 235 Authentication successful
11:17:07 [xx.xx.xx.xx][15459629] Authenticated as hackedaccount@domain1.com
11:17:07 [xx.xx.xx.xx][15459629] cmd: MAIL FROM:
11:17:07 [xx.xx.xx.xx][15459629] rsp: 250 OK <> Sender ok
11:17:07 [xx.xx.xx.xx][15459629] cmd: RCPT TO:recipient@domain2.com
11:17:07 [xx.xx.xx.xx][15459629] rsp: 250 OK <recipient@domain2.com> Recipient ok
11:17:08 [xx.xx.xx.xx][15459629] cmd: DATA

Respostas:


23

O vazio MAIL FROMé usado para notificações de status de entrega. Servidores de correio são necessários para suportá-lo ( seção 5.2.9 da RFC 1123 ).

É usado principalmente para mensagens de devolução, para evitar um loop sem fim. Quando MAIL FROMé usado com um endereço vazio (representado como <>), o servidor de recebimento sabe que não deve gerar uma mensagem de devolução se a mensagem estiver sendo enviada para um usuário inexistente.

Sem isso, pode ser possível que alguém faça DoS simplesmente falsificando uma mensagem para um usuário inexistente em outro domínio, com o endereço de retorno de um usuário inexistente em seu próprio domínio, resultando em um loop sem fim de devolver mensagens.

O que aconteceria se você bloquear mensagens com um vazio MAIL FROM:?

  • Seus usuários não receberiam mensagens devolvidas de outros domínios: eles nunca saberiam se cometeram um erro de digitação ao enviar e-mails para um usuário em outro domínio.

As MAIL FROM:mensagens vazias que você está vendo provavelmente não são provenientes de um remetente de spam.

Em vez disso, um remetente de spam falsificou um endereço no seu domínio e o usou como endereço de retorno de uma mensagem para outro domínio. Digamos que você é yourdomain.come meu domínio é mydomain.net. O remetente de spam envia uma mensagem para johnq@mydomain.net, fingindo o endereço de retorno como johnq@yourdomain.com. Como não há usuário johnqno meu domínio, meu servidor de email envia uma mensagem de devolução ( MAIL FROM:<>) ao remetente aparente johnq@yourdomain.com,. Isso é o que você provavelmente está vendo.

Bloquear MAIL FROMmensagens vazias fará mais mal do que bem, na minha opinião. Na minha experiência, os spammers raramente usam um espaço vazio, MAIL FROM:pois podem facilmente falsificar um endereço de aparência real. Quando a mensagem é spam real, existem maneiras muito melhores de detectá-la e bloqueá-la, incluindo RBLs, filtros bayesianos e SpamAssassin.

E, finalmente, você pode impedir pelo menos algumas falsificações usando a yourdomain.comconfiguração de registros SPF adequados para o seu domínio.

Atualização: depois de olhar mais de perto o seu log, alguém conseguiu AUTHusar um nome de usuário e senha válidos para o seu servidor. Isso coloca uma outra categoria de problemas. No entanto, tudo o que eu disse sobre MAIL FROM:ainda permanece. 99% do tempo será o resultado de mensagens devolvidas.


Muito obrigado! É muito útil. Eu deveria fazer essa pergunta mais cedo. :)
garconcn

Feliz em ajudar. Por favor, veja a "Atualização" que eu adicionei.
Nate

1

Você pode procurar a opção do servidor de email para limitar MAIL FROM ao email de usuário autenticado. Muitos sistemas de correio aplicam essa limitação.

E assim, force os usuários invadidos a alterar a senha.


Tentamos limitar o MAIL FROM a emails de usuários autenticados antes, mas isso causava que o cliente não pudesse enviar email se tivesse várias contas de email no cliente POP. Depois que encontramos a conta invadida, alteramos a senha imediatamente. Obrigado.
garconcn
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.