Email di spam senza indirizzo "to:". Filtrare con Postfix..?

Supporto
1

Il mio forum è stato recentemente inondato da una serie di spam email simili. Usano un mittente, un dominio e un IP diversi ogni volta. (Ma sono sempre su qualche conferenza del settore edile da qualche parte.)

Finiscono in Rifiutati con Email::Receiver::BadDestinationAddress, e il sistema tenta di inviare un messaggio di rifiuto all’indirizzo del mittente non valido. Uffa, registro ingombro.

In effetti, non hanno alcun indirizzo to: o cc: negli header. Ho imparato che i destinatari sono effettivamente definiti nell’envelope SMTP, non nell’header, e che i sistemi di mailing list potrebbero omettere intenzionalmente to:/cc: dagli header.

Non ho voglia di addentrarmi nella configurazione di Postfix, ma apparentemente può fare controlli sugli header…

Mi chiedo se qualcuno l’abbia già provato e abbia qualche consiglio?

header di esempio di spam, per completezza 
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

Di solito inviano in copia nascosta (bcc) a una lunga lista di email raccolte automaticamente, ho visto questo comportamento su alcuni siti, ma non ho ancora una soluzione pratica.

3

Sì, è così che funziona il Ccn:, l’indirizzo semplicemente non compare in un’intestazione.

Discourse è un po’ diverso in quanto non utilizza affatto il destinatario della busta, ma solo le intestazioni. Si potrebbe sostenere che questo sia sbagliato, ma così tante persone dipendono dal comportamento attuale che è difficile cambiarlo.

Il Rifiuto Veloce è stato rimosso perché non funzionava. Inoltre, la logica controllava il destinatario della busta, che non corrisponde a ciò che Discourse cerca. Questa discrepanza significa che il rifiuto veloce potrebbe rifiutare posta altrimenti consegnabile e consentire quella non consegnabile.

Riconciliare questo sarebbe sfortunatamente uno sforzo complicato per un guadagno relativamente piccolo.

4

Capisco… grazie per i dettagli.

Attualmente uso solo la risposta via email, quindi ho pensato che avrebbe avuto senso bloccare qualsiasi cosa senza un’intestazione TO:/CC:. Ma posso immaginare come questo possa essere problematico per i siti che utilizzano la pubblicazione via email.

5

Riconciliare questo sarebbe purtroppo uno sforzo complicato per un guadagno relativamente piccolo.

Sono certamente di parte: ho scritto il codice di rifiuto veloce che è stato rimosso, ma non sarei d’accordo sul valore del concetto, specialmente se il backscatter iniziasse a far finire i server Discourse delle persone nelle blocklist dello spam, o se servizi come Mailgun iniziassero a lamentarsi (o peggio, se non si lamentassero e ti addebitassero volentieri di inviare tonnellate di email false quando un’ondata di spammer colpisce).

Se qualcun altro contribuisse con codice per risolvere le preoccupazioni (analizzare le intestazioni invece della busta, ecc.), sarebbe qualcosa che Discourse sarebbe disposto a reintegrare, o è semplicemente qualcosa con cui nessuno ha tempo di armeggiare in alcun modo al momento?

(In entrambi i casi va bene, capisco perfettamente che tutti stiano facendo del loro meglio con tempo e risorse limitate!)

6

Ehi, solo alcuni suggerimenti che ho provato per questo tipo di spam:

- Per i messaggi senza intestazioni To:/Cc:, eliminarli a livello Postfix funziona bene se usi solo la risposta via email.

- Puoi anche aggiungere un semplice controllo SPF/DKIM per filtrare i domini falsificati prima che raggiungano Discourse.

- Un altro trucco che ho visto è limitare la frequenza delle email in arrivo per IP o per dominio del mittente: aiuta a rallentare le ondate di spam senza toccare gli utenti normali.

- Se ti senti avventuroso, combinare i controlli delle intestazioni con una piccola whitelist (per mittenti fidati o mailing list) può ridurre i falsi positivi.

Niente di speciale, solo alcune idee che mi hanno aiutato a ridurre un po’ il rumore :slightly_smiling_face: