没有“to:”地址的垃圾邮件。用 Postfix 过滤?

我的论坛最近被一系列类似的垃圾邮件轰炸。它们每次都使用不同的发件人、域名和 IP。(但它们总是关于某个建筑行业的会议。)

它们最终被归类到“拒绝”中,并带有 Email::Receiver::BadDestinationAddress 错误,系统会尝试向无效的发件人地址发送拒绝邮件。哎呀,日志太乱了。

事实上,它们根本没有 to:cc: 地址。我了解到收件人实际上是在 SMTP 信封中定义的,而不是在邮件头中,并且邮件列表系统可能会故意省略 to:/cc: 字段。

我不太愿意深入研究 Postfix 配置,但显然它可以进行邮件头检查

想知道是否有人已经尝试过并有什么建议?

FWIW 示例垃圾邮件头
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:

他们通常以密送(bcc)的方式发送给一长串抓取的电子邮件地址,我在一些网站上见过这种行为,但还没有任何实际的解决方案。

是的,BCC: 就是这样做的,地址只是没有出现在邮件头中。

Discourse 有点不同,因为它根本不使用信封收件人,只使用邮件头。可以说这是错误的,但有太多人依赖当前的这种行为,所以很难改变。

快速拒绝功能已被移除,因为它已损坏。最重要的是,该逻辑检查的是信封收件人,这与 Discourse 查找的内容不匹配。这种不匹配意味着快速拒绝可能会拒绝本应可投递的邮件,同时允许不可投递的邮件通过。

不幸的是,协调这一点将是一项艰巨的工作,但收益却相对较小。

我明白了……感谢您的详细信息。

我目前只使用邮件回复,所以我想阻止任何没有 TO:/CC: 标头的邮件。但我可以想象这对于使用邮件发帖的网站来说可能会很麻烦。

调和这一点不幸地将是一项艰巨的工作,但收益却微乎其微。

我当然有偏见——我编写了被移除的快速拒绝代码——但我不同意这个概念的价值,特别是如果“反弹”(backscatter)开始导致人们的 Discourse 服务器被列入垃圾邮件黑名单,或者像 Mailgun 这样的服务开始对此抱怨(或者更糟,他们抱怨,而是乐于收取费用来发送大量虚假电子邮件,当一大波垃圾邮件发送者涌入时)。

如果其他人能贡献代码来解决这些担忧(例如,解析标头而不是信封等),Discourse 是否愿意重新采纳它,还是目前只是没有人有时间去处理任何方面的事情?

(无论哪种情况都可以,我完全理解每个人都在用有限的时间和资源尽其所能!)

嘿,我尝试了一些针对这类垃圾邮件的技巧:

- 对于没有 To:/Cc: 标头的邮件,如果你只使用回复邮件,在 Postfix 级别将其丢弃效果很好。

- 你还可以添加一个简单的 SPF/DKIM 检查,在邮件到达 Discourse 之前过滤掉伪造的域名。

- 我见过的另一个技巧是按 IP 或按发件人域名限制传入邮件的速率——这有助于减缓垃圾邮件浪潮,而不会影响正常用户。

- 如果你愿意尝试更进一步,将标头检查与小的白名单(用于受信任的发件人或邮件列表)结合起来可以减少误报。

没什么花哨的,只是一些帮助我减少噪音的想法 :slightly_smiling_face: