Spam-E-Mails ohne „An:“-Adresse. Mit Postfix filtern..?

Unterstützung
1

Mein Forum wird in letzter Zeit mit einer Reihe ähnlicher Spam-E-Mails überschwemmt. Sie verwenden jedes Mal einen anderen Absender, eine andere Domain und eine andere IP-Adresse. (Aber es geht immer um irgendeine Konferenz der Bauindustrie irgendwo.)

Sie landen unter “Abgelehnt” mit Email::Receiver::BadDestinationAddress, und das System versucht, eine Ablehnungsnachricht an die ungültige Absenderadresse zu senden. Ugh, Protokollmüll.

Tatsächlich haben sie keine to:- oder cc:-Adresse. Ich habe gelernt, dass Empfänger eigentlich in der SMTP-Hülle (Envelope) und nicht im Header definiert sind und dass Mailinglisten-Systeme to:/cc: aus den Headern weglassen können, und das mit Absicht.

Ich habe keine Lust, mich in die Postfix-Konfiguration zu vertiefen, aber anscheinend kann diese Header-Prüfungen durchführen…

Ich frage mich, ob das schon jemand versucht hat und ob es Tipps gibt?

Beispiel-Spam-E-Mail-Header, nur zur Info 
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

Sie senden normalerweise an eine lange Liste von gescrapten E-Mails als bcc, ich habe dieses Verhalten auf einigen Websites gesehen, habe aber noch keine praktische Lösung.

3

Ja, das ist die Funktionsweise von BCC: die Adresse gelangt einfach nicht in einen Header.

Discourse ist etwas anders, da es den Envelope-Empfänger überhaupt nicht verwendet, sondern nur die Header. Das ist zwar strittig, aber so viele Leute verlassen sich auf das aktuelle Verhalten, dass es schwer ist, es zu ändern.

Fast Rejection wurde entfernt, da es fehlerhaft war. Darüber hinaus prüfte die Logik den Envelope-Empfänger, was nicht mit dem übereinstimmt, wonach Discourse sucht. Diese Nichtübereinstimmung bedeutet, dass Fast-Rejection E-Mails, die eigentlich zustellbar wären, ablehnen und nicht zustellbare E-Mails durchlassen könnte.

Dies in Einklang zu bringen, wäre leider ein mühsamer Aufwand für einen vergleichsweise geringen Nutzen.

4

Ich verstehe… danke für die Details.

Ich verwende derzeit nur die Antwort per E-Mail, daher dachte ich, es wäre sinnvoll, alles ohne einen TO:/CC:-Header zu blockieren. Aber ich kann mir vorstellen, wie problematisch das für Websites sein könnte, die das Posten per E-Mail verwenden.

5

Dies abzugleichen wäre leider ein mühsamer Aufwand für einen vergleichsweise geringen Gewinn.

Ich bin sicherlich voreingenommen – ich habe den Code zur schnellen Ablehnung geschrieben, der entfernt wurde –, aber ich würde dem Wert des Konzepts widersprechen, insbesondere wenn der Rückstreuer anfängt, die Discourse-Server von Leuten auf Spam-Blocklisten zu setzen, oder Dienste wie Mailgun sich darüber beschweren (oder schlimmer noch, sie beschweren sich nicht und berechnen Ihnen gerne, riesige Mengen an gefälschten E-Mails zu senden, wenn eine große Welle von Spammern durchrauscht).

Wenn jemand anderes Code beisteuern würde, um die Bedenken auszuräumen (z. B. die Header anstelle des Umschlags zu parsen), wäre dies etwas, das Discourse wieder aufnehmen würde, oder ist dies momentan einfach etwas, womit sich niemand in irgendeiner Weise beschäftigen möchte?

(Jede Möglichkeit ist in Ordnung, ich verstehe vollkommen, dass jeder mit begrenzter Zeit und begrenzten Ressourcen sein Bestes gibt!)

6

Hallo, hier sind ein paar Tipps, die ich bei dieser Art von Spam ausprobiert habe:

- Bei Nachrichten ohne To:/Cc:-Header ist das Ablegen auf Postfix-Ebene gut, wenn Sie nur per E-Mail antworten.

- Sie können auch eine einfache SPF/DKIM-Prüfung hinzufügen, um gefälschte Domains herauszufiltern, bevor sie Discourse erreichen.

- Ein weiterer Trick, den ich gesehen habe, ist die Ratenbegrenzung eingehender E-Mails pro IP oder pro Absenderdomäne – das hilft, Spamwellen zu verlangsamen, ohne normale Benutzer zu beeinträchtigen.

- Wenn Sie abenteuerlustig sind, kann die Kombination von Header-Prüfungen mit einer kleinen Whitelist (für vertrauenswürdige Absender oder Mailinglisten) die Fehlalarme reduzieren.

Nichts Besonderes, nur ein paar Ideen, die mir geholfen haben, das Rauschen etwas zu reduzieren :slightly_smiling_face: