宛先に「to:」がないスパムメール。Postfixでフィルタリングできますか？

サポート
1

私のフォーラムは最近、一連の類似したスパムメールで頻繁に攻撃されています。送信者、ドメイン、IPアドレスは毎回異なります。（しかし、いつもどこかの建設業界のカンファレンスに関するものです。）

それらは Rejected の Email::Receiver::BadDestinationAddress に分類され、システムは無効な送信者アドレスに拒否メッセージを送信しようとします。うーん、ログが散らかります。

実際、それらには to: や cc: アドレスがまったくありません。受信者はヘッダーではなくSMTPエンベロープで実際に定義されており、メーリングリストシステムは意図的にヘッダーから to:/cc: を省略する場合があることを学びました。

Postfix の設定を深く掘り下げるのは気が進みませんが、どうやら ヘッダーチェックができるようです…

誰かこれを試した人がいて、何かヒントを持っているか知りたいです。

参考情報として、スパムメールのヘッダー例 
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

通常、スクレイピングされた長いメールリストにBCCで送信されます。いくつかのサイトでその動作を確認しましたが、まだ実用的な解決策はありません。

3

ええ、これはBCC:がどのように行われるかというもので、アドレスがヘッダーに到達しないだけです。

Discourseは、エンベロープの受信者を一切使用せず、ヘッダーのみを使用するという点で少し異なります。これは間違いであると主張することもできますが、現在の動作に依存している人が多すぎるため、変更するのは困難です。

Fast Rejectionは、壊れていたため削除されました。それに加えて、ロジックはエンベロープの受信者をチェックしていましたが、これはDiscourseが探すものと一致しません。この不一致により、fast-rejectionは配信可能なはずのメールを拒否し、配信不可能なメールを許可する可能性があります。

これを調整することは、得られる利益が比較的小さい割には、残念ながら厄介な作業になります。

4

なるほど…詳細ありがとうございます。

私は現在、メールでの返信機能のみを使用しているので、TO:/CC: ヘッダーがないものはすべてブロックするのが理にかなっていると考えていました。しかし、メールでの投稿機能を使用しているサイトにとっては問題になる可能性があることは想像できます。

5

これを調整するのは、得られる利益に対して残念ながら厄介な作業になるでしょう。

私は確かに偏見を持っています。削除された高速拒否コードを書いたのは私ですが、その概念の価値については同意しません。特に、バックscatterによってDiscourseサーバーがスパムブロックリストに載せられたり、Mailgunのようなサービスが苦情を言い始めたりする（あるいは最悪なことに、苦情を言わずに大量の偽のメールを送信することに対して喜んで料金を請求したりする）場合です。

もし誰かが懸念を解消するためのコード（エンベロープの代わりにヘッダーを解析するなど）を提供してくれるなら、Discourseはこれを再統合するつもりがあるでしょうか、それとも現時点では誰もそれに時間を割く余裕がないということでしょうか？

（どちらの状況でも構いません。皆さんが限られた時間とリソースの中で最善を尽くしていることは完全に理解しています！）

6

こんにちは、この種のスパムに対して私が試しているいくつかのヒントを紹介します。

  • To:/Cc: ヘッダーのないメッセージについては、返信はメールのみを使用している場合、Postfixレベルで破棄するのが効果的です。

  • なりすまされたドメインをDiscourseに到達する前にフィルタリングするために、単純なSPF/DKIMチェックを追加することもできます。

  • 私が見た別のトリックは、IPごと、または送信者ドメインごとに着信メールをレート制限することです。これにより、通常のユーザーに影響を与えることなく、スパムの波を遅らせることができます。

  • 試してみる気があれば、ヘッダーチェックと小さなホワイトリスト（信頼できる送信者やメーリングリスト用）を組み合わせることで、誤検知を減らすことができます。

大したことではありませんが、ノイズを少し減らすのに役立ったアイデアです :slightly_smiling_face: