Emails de spam sans adresse "to:". Filtrer avec Postfix..?

Soutien
1

Mon forum est récemment inondé d’une série de spams par e-mail similaires. Ils utilisent un expéditeur, un domaine et une IP différents à chaque fois. (Mais ils concernent toujours une conférence sur l’industrie de la construction quelque part.)

Ils se retrouvent dans Rejetés avec Email::Receiver::BadDestinationAddress, et le système tente d’envoyer un message de rejet à l’adresse de l’expéditeur invalide. Argh, encombrement des journaux.

En fait, ils n’ont pas d’adresse to: ou cc: du tout. J’ai appris que les destinataires sont réellement définis dans l’enveloppe SMTP, et non dans l’en-tête, et que les systèmes de listes de diffusion peuvent omettre to:/cc: des en-têtes intentionnellement.

Je n’ai pas envie de plonger dans la configuration de Postfix, mais apparemment, cela peut effectuer des vérifications d’en-tête…

Je me demande si quelqu’un a déjà essayé cela et a des conseils ?

en-tête d'e-mail de spam exemple, pour information 
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

Ils envoient généralement en copie cachée (bcc) à une longue liste d’e-mails récupérés, j’ai vu ce comportement sur quelques sites, mais je n’ai pas encore de solution pratique.

3

Oui, c’est ainsi que le BCC: est géré, l’adresse n’apparaît tout simplement pas dans un en-tête.

Discourse est un peu différent car il n’utilise pas du tout le destinataire de l’enveloppe, mais uniquement les en-têtes. C’est discutablement faux, mais tellement de personnes dépendent du comportement actuel qu’il est difficile de changer.

Le rejet rapide (Fast Rejection) a été supprimé car il était défectueux. En plus de cela, la logique vérifiait le destinataire de l’enveloppe, ce qui ne correspond pas à ce que Discourse recherche. Ce décalage signifie que le rejet rapide pourrait rejeter des courriels autrement livrables et autoriser des courriels non livrables.

Régler cela serait malheureusement un effort épineux pour un gain comparativement faible.

4

Je vois… merci pour les détails.

J’utilise actuellement uniquement la réponse par e-mail, donc j’ai pensé qu’il serait logique de bloquer tout ce qui n’a pas d’en-tête TO:/CC:. Mais je peux imaginer à quel point cela pourrait être problématique pour les sites qui utilisent la publication par e-mail.

5

Réconcilier cela serait malheureusement un effort épineux pour un gain comparativement faible.

Je suis certainement partial — j’ai écrit le code de rejet rapide qui a été supprimé — mais je ne serais pas d’accord sur la valeur du concept, surtout si le backscatter commence à faire figurer les serveurs Discourse des utilisateurs sur des listes noires de spam, ou si des services comme Mailgun commencent à s’en plaindre (ou pire, s’ils ne s’en plaignent pas et vous facturent volontiers l’envoi de tonnes de courriels bidons lorsqu’une grosse vague de spammeurs déferle).

Si quelqu’un d’autre contribuait du code pour résoudre les problèmes (analyser les en-têtes au lieu de l’enveloppe, etc.), serait-ce quelque chose que Discourse serait prêt à réintégrer, ou est-ce simplement quelque chose avec lequel personne n’a le temps de s’embêter actuellement ?

(Dans tous les cas, ça me va, je comprends tout à fait que chacun fait de son mieux avec un temps et des ressources limités !)

6

Salut, voici quelques astuces que j’ai essayées pour ce type de spam :

  • Pour les messages sans en-têtes To:/Cc:, les rejeter au niveau de Postfix fonctionne bien si vous n’utilisez que la réponse par e-mail.

  • Vous pouvez également ajouter une simple vérification SPF/DKIM pour filtrer les domaines usurpés avant qu’ils n’atteignent Discourse.

  • Une autre astuce que j’ai vue consiste à limiter le débit du courrier entrant par adresse IP ou par domaine d’expéditeur — cela aide à ralentir les vagues de spam sans affecter les utilisateurs normaux.

  • Si vous êtes d’humeur aventureuse, combiner les vérifications d’en-tête avec une petite liste blanche (pour les expéditeurs de confiance ou les listes de diffusion) peut réduire les faux positifs.

Rien de bien compliqué, juste quelques idées qui m’ont aidé à réduire un peu le bruit :slightly_smiling_face: