E-mails de spam sem endereço "to:". Filtrar com Postfix..?

Suporte
1

Meu fórum está sendo bombardeado recentemente com uma série de e-mails de spam semelhantes. Eles usam um remetente, domínio e IP diferentes a cada vez. (Mas são sempre sobre alguma conferência da indústria da construção em algum lugar.)

Eles acabam em Rejeitados com Email::Receiver::BadDestinationAddress, e o sistema tenta enviar uma mensagem de rejeição para o endereço de remetente inválido. Ugh, poluição de log.

Na verdade, eles não têm nenhum endereço to: ou cc: no cabeçalho. Eu aprendi que os destinatários são realmente definidos no envelope SMTP, e não no cabeçalho, e que sistemas de lista de e-mail podem omitir to:/cc: dos cabeçalhos de propósito.

Não estou animado para mergulhar na configuração do Postfix, mas aparentemente ele pode fazer verificações de cabeçalho…

Gostaria de saber se alguém já tentou isso e tem alguma dica?

cabeçalho de e-mail de spam de exemplo, para referência 
Received: from 103-191-76-30.cprapid.com (unknown [103.191.76.30])	by forum-mail-receiver.localdomain (Postfix) with ESMTPS id 0845A2FB2B6; Thu, 08 Jan 2026 02:30:19 +0000
Received: from [::1] (port=57140 helo=103-191-76-30.cprapid.com)	by 103-191-76-30.cprapid.com with esmtpa (Exim 4.99.1)	(envelope-from <alexg@connectconsortiumplaceru.com>)id 1vdfl5-00000000rLO-0bcP; Wed, 07 Jan 2026 21:28:18 -0500
Date: Wed, 07 Jan 2026 21:26:55 -0500
From: alexg@connectconsortiumplaceru.com
Message-ID: <093f4b04eb0e41f70390cf63dcce77d4@connectconsortiumplaceru.com>
Subject: 5th Annual Modular Construction & Prefabrication Symposium - Toronto,
 Canada | March 2026 (Limited Seats Left)
MIME-Version: 1.0
Content-Type: multipart/mixed;
 boundary="=_605ba79265fcf8605b02d6716c2455fc";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Authentication-Results: forum-mail-receiver.localdomain; dmarc=none (p=none
 dis=none) header.from=connectconsortiumplaceru.com
Authentication-Results: forum-mail-receiver.localdomain; dkim=pass (2048-bit
 key; unprotected) header.d=connectconsortiumplaceru.com
 header.i=@connectconsortiumplaceru.com header.a=rsa-sha256 header.s=default
 header.b=hljdS4ya; dkim-atps=neutral
Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=103.191.76.30;
 helo=103-191-76-30.cprapid.com;
 envelope-from=alexg@connectconsortiumplaceru.com; receiver=forum.tasat.org
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
 d=connectconsortiumplaceru.com; s=default; h=Content-Type:Message-ID:Subject:
 To:From:Date:MIME-Version:Sender:Reply-To:Cc:Content-Transfer-Encoding:
 Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender:
 Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id:
 List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive;
 bh=QsuKb3maShWc9C0uTAfGJZlp0GLvUFzREukTJkY4TbE=; b=hljdS4yaocpaFXSAbqnR+pvdM5
 W02vREZeWNQEtDMCqxEmI17jqjL5k+VGWi6vcruI2QBIi+C3omMWl1MrzAZ18EotG4/SfmY0jqcyV
 G5lu46MfkyxsUUdqQoKIHChQ5T0aa7jfc7LzZzM8bIBUk6VnV4lNn5SItSDEMAzRqrq66rL7ugL3u
 16OkrMph0Kjw7YP2swVhZY9y0TqJBy0L05XHy5BfLjh5K7UGbNxnnN6daXlpCJ/zsQPFjjkiTNicc
 WLIuKHpH+sCQt2VqnbvGVcdYJmapKCzXn0sS08BspidViHbf/2hOAHkDlbVyWduINyn44Es5oj2Jh
 B9+D9w8g==;
User-Agent: Roundcube Webmail/1.6.12
X-Sender: alexg@connectconsortiumplaceru.com
X-AntiAbuse: This header was added to track abuse, please include it with any
 abuse report
X-AntiAbuse: Primary Hostname - 103-191-76-30.cprapid.com
X-AntiAbuse: Original Domain - forum.tasat.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - connectconsortiumplaceru.com
X-Get-Message-Sender-Via: 103-191-76-30.cprapid.com: authenticated_id:
 alexg@connectconsortiumplaceru.com
X-Authenticated-Sender: 103-191-76-30.cprapid.com:
 alexg@connectconsortiumplaceru.com
X-Source: 
X-Source-Args: 
X-Source-Dir:
2

Eles geralmente enviam para como cópia oculta (bcc) para uma longa lista de e-mails raspados, eu vi esse comportamento em alguns sites, mas ainda não tenho nenhuma solução prática.

3

Sim, é assim que o BCC: é feito, o endereço simplesmente não chega a um cabeçalho.

O Discourse é um pouco diferente, pois não usa o destinatário do envelope de forma alguma, apenas os cabeçalhos. Argumentavelmente, isso está errado, mas tantas pessoas dependem do comportamento atual que é difícil mudar.

A Rejeição Rápida foi removida porque estava com defeito. Além disso, a lógica verificava o destinatário do envelope, o que não corresponde ao que o Discourse procura. Essa incompatibilidade significa que a rejeição rápida pode rejeitar e-mails que seriam entregues, e permitir e-mails que não seriam entregues.

Conciliar isso seria, infelizmente, um esforço complicado para um ganho relativamente pequeno.

4

Entendo… obrigado pelos detalhes.

Atualmente, eu só uso resposta por e-mail, então imaginei que faria sentido bloquear qualquer coisa sem o cabeçalho TO:/CC:. Mas consigo imaginar como isso pode ser problemático para sites que usam postagem por e-mail.

5

Conciliar isso seria, infelizmente, um esforço complicado para um ganho relativamente pequeno.

Eu certamente sou tendencioso — eu escrevi o código de rejeição rápida que foi removido — mas eu discordaria sobre o valor do conceito, especialmente se o backscatter começar a colocar os servidores do Discourse das pessoas em listas de bloqueio de spam, ou se serviços como o Mailgun começarem a reclamar disso (ou pior, eles não reclamarem e ficarem felizes em cobrar por enviar muitos e-mails falsos quando uma grande onda de spammers passar).

Se outra pessoa contribuísse com código para resolver as preocupações (analisar os cabeçalhos em vez do envelope, etc.), isso seria algo que o Discourse estaria disposto a reincorporar, ou é apenas algo com que ninguém tem tempo para mexer em nenhuma capacidade no momento?

(De qualquer forma está bom, eu entendo totalmente que todos estão fazendo o melhor que podem com tempo e recursos limitados!)

6

Ei, apenas algumas dicas que tenho usado para este tipo de spam:

- Para mensagens sem cabeçalhos To:/Cc:, descartá-las no nível do Postfix funciona bem se você usa apenas resposta por e-mail.

- Você também pode adicionar uma verificação simples de SPF/DKIM para filtrar domínios falsificados antes que cheguem ao Discourse.

- Outro truque que vi é limitar a taxa de e-mails recebidos por IP ou por domínio do remetente — ajuda a retardar as ondas de spam sem afetar usuários normais.

- Se você estiver se sentindo aventureiro, combinar verificações de cabeçalho com uma pequena lista de permissões (para remetentes confiáveis ou listas de discussão) pode reduzir falsos positivos.

Nada complicado, apenas algumas ideias que me ajudaram a reduzir um pouco o ruído :slightly_smiling_face: