From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wopr.sciops.net ([216.126.196.60]) by ewsd; Tue Sep 22 15:38:41 EDT 2020 Received: (qmail 88846 invoked by uid 1001); 22 Sep 2020 12:38:34 -0700 Date: Tue, 22 Sep 2020 12:38:34 -0700 From: Kurt H Maier To: 9front@9front.org Subject: Re: *****SPAM***** [9front] test Message-ID: <20200922193834.GB55738@wopr> Mail-Followup-To: 9front@9front.org References: <1E3083B627E4EDD1DF08AA61E95E4DA2@a-b.xyz> <20200921195429.4839eb21@lenovo.sphairon.box> <20200921203300.GD43872@wopr> <20200922205721.27248d34@lenovo.sphairon.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200922205721.27248d34@lenovo.sphairon.box> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: basic transactional core standard STM manager This is where the confusion is coming from. Notes inline. On Tue, Sep 22, 2020 at 08:57:21PM +0200, Stefan Hertenberger wrote: > Return-Path: <9front-bounces@ewsd.inri.net> > X-Original-To: stefan@alarum.de > Delivered-To: stefan@alarum.de > Received: from ewsd.inri.net (ewsd.inri.net [107.191.116.128]) > by alarum.de (Postfix) with ESMTP id 4FFC71B8D67 > for ; Mon, 21 Sep 2020 17:41:37 +0200 (CEST) This is the Received header that alarum SpamAssassin should be looking at. > Received: from out0.migadu.com ([94.23.1.103]) by ewsd; Mon Sep 21 > 11:40:32 EDT 2020 Message-ID: <1E3083B627E4EDD1DF08AA61E95E4DA2@a-b.xyz> This is the one it's actually looking at, which is why it's blaming migadu for all kinds of shenanigans. I don't know why it's choosing the wrong one, but the fact that the second line is incorrectly folded may be causing the system to read the header as ending after "Mon Sep 21". Proper folding would have immediately followed the linebreak with a folding-whitespace character (ascii space or tab). > X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and > include these headers. From: kvik@a-b.xyz Same thing here. Note the embedded header in this header. Valid, but could confuse software in this case, especially as I see no sign of an actual From: header in the rest of the message. The improper folding might be causing SA to identify this as the From: header. > X-Bullshit: virtualized metadata metadata-based dependency-aware > backend Subject: *****SPAM***** [9front] test More improper folding, leading to the Subject: line being munged. Something is mangling messages before they're getting handed to SpamAssassin. The copy I received on my mailserver was not mangled, so I must presume it's something on vbsd.alarum.de. The fact that the SPF testing is in the SA report but not set as headers tells me it's likel that the SA run was done after receipt of the message instead of during the SMTP handshake, so the problem is somewhere between your MTA and your SpamAssassin run. The absent From: header combined with the mangled X-Abuse: header probably tricked SA into applying the NTLD rules for .xyz. That problem would be fixed alongside the other mangling-based problems, but I really do recommend turning those rules off anyway, or at least whitelisting TLDs you know people are legitimately using. Hope this helps, khm