수신인 주소가 없는 스팸 이메일. Postfix로 필터링할 수 있을까요?

최근 제 포럼에 비슷한 스팸 이메일이 연이어 들어오고 있습니다. 매번 발신자, 도메인, IP 주소가 모두 다릅니다. (하지만 내용물은 어디선가 열리는 건설 산업 컨퍼런스에 대한 것입니다.)

이메일들은 Email::Receiver::BadDestinationAddress 오류로 거부(Removed) 처리되며, 무효한 발신자 주소로 거부 메시지를 보내려고 시도합니다. 거부 메시지를 발송하여 백스캐터(backscatter)를 발생시킵니다. 참고: 발신자 주소가 무효하다는 증거는 없습니다.

사실, 해당 이메일에는 to:cc: 주소가 전혀 없습니다. 수신자는 헤더가 아닌 SMTP 엔벨로프에서 실제로 정의되며, 메일링 리스트 시스템이 의도적으로 헤더에서 to:/cc:를 생략할 수 있다는 것을 알게 되었습니다.

(이 문제가 11월에 시작되었는데, fast-rejection 기능이 제거된 시기와 일치합니다 :thinking:)

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:

보통 그들은 긁어모은 이메일 주소의 긴 목록을 BCC로 보내는데, 몇몇 사이트에서 그런 행동을 본 적이 있지만 아직 실용적인 해결책은 없습니다.

네, BCC:가 바로 이렇게 작동하는 방식입니다. 주소가 단순히 헤더에 포함되지 않을 뿐이죠.

Discourse는 이 부분에서 약간 다릅니다. Discourse는 엔벨로프 수신자를 전혀 사용하지 않고 헤더만 사용합니다. 논리적으로 보면 이는 잘못된 방식일 수 있지만, 현재 동작 방식에 의존하는 사람이 너무 많아 변경하기가 어렵습니다.

Fast Rejection은 오류가 있어 제거되었습니다. 게다가 해당 로직은 엔벨로프 수신자를 확인했는데, 이는 Discourse가 찾는 내용과 일치하지 않습니다. 이러한 불일치는 배달 가능한 메일을 Fast Rejection이 거부하거나, 배달 불가능한 메일을 허용할 수 있는 문제를 일으킵니다.

이를 조정하는 것은 비교적으로 적은 이점에 비해 매우 까다로운 작업이 될 것입니다.

아, 그렇군요. 자세한 설명 감사합니다.

저는 현재 이메일로 답장하는 기능만 사용하고 있어서, TO:/CC: 헤더가 없는 메시지는 모두 차단하는 것이 합리적이라고 생각했습니다. 하지만 이메일로 게시하는 기능을 사용하는 사이트에서는 이것이 문제가 될 수 있다는 점은 충분히 이해합니다.

이를 조정하는 것은 불행히도 상대적으로 적은 이득에 비해 매우 복잡한 작업이 될 것입니다.

저는 분명 편견이 있습니다—제거된 빠른 거부(fast-rejection) 코드를 제가 작성했으니까요—하지만 이 개념의 가치에 대해서는 동의하지 않습니다. 특히 백스캐터(backscatter)로 인해 사람들의 Discourse 서버가 스팸 차단 목록에 오르게 되거나, Mailgun과 같은 서비스가 이를 문제 삼기 시작할 경우(또는 더 나쁘게 말해, 그들이 이를 문제 삼지 않고 스팸 공격자가 대거 몰려들 때 대량의 가짜 이메일을 보내는 데 기꺼이 비용을 청구할 경우)에는 더욱 그렇습니다.

다른 누군가가 이러한 우려를 해결하기 위해 코드를 기여한다면(봉투(envelope) 대신 헤더를 파싱하는 등), Discourse가 이를 다시 통합할 의사가 있는 것입니까, 아니면 현재로서는 아무도 시간을 들여 이 문제를 다룰 여력이 없는 것입니까?

(어떤 답변이든 괜찮습니다. 모든 사람이 제한된 시간과 자원 내에서 최선의 노력을 다하고 있다는 점을 충분히 이해합니다!)

안녕하세요, 이런 종류의 스팸에 대해 제가 직접 테스트해 본 몇 가지 팁을 공유할게요:

- To:/Cc: 헤더가 없는 메시지의 경우, 이메일 회신 방식만 사용한다면 Postfix 레벨에서 메시지를 차단하는 것이 효과적입니다.

- 또한 SPF/DKIM 검사를 간단히 추가하여 위조된 도메인이 Discourse에 도달하기 전에 필터링할 수 있습니다.

- 제가 본 또 다른 방법은 IP 또는 발신자 도메인별 수신 메일 레이트 리미팅입니다. 이는 일반 사용자에게 영향을 주지 않으면서 스팸 물결을 늦추는 데 도움이 됩니다.

- 조금 더 도전적인 방법을 원하신다면, 헤더 검사와 소규모 화이트리스트(신뢰할 수 있는 발신자 또는 메일링 리스트용)를 결합하면 오탐(false positive)을 줄일 수 있습니다.

특별히 복잡한 것은 아니지만, 소음(스팸)을 조금이나마 줄이는 데 도움이 된 아이디어들입니다 :slightly_smiling_face: