From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wopr.sciops.net ([216.126.196.60]) by ewsd; Mon Sep 21 16:33:24 EDT 2020 Received: (qmail 40487 invoked by uid 1001); 21 Sep 2020 13:33:00 -0700 Date: Mon, 21 Sep 2020 13:33:00 -0700 From: Kurt H Maier To: 9front@9front.org Subject: Re: *****SPAM***** [9front] test Message-ID: <20200921203300.GD43872@wopr> Mail-Followup-To: 9front@9front.org References: <1E3083B627E4EDD1DF08AA61E95E4DA2@a-b.xyz> <20200921195429.4839eb21@lenovo.sphairon.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200921195429.4839eb21@lenovo.sphairon.box> List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: converged object-oriented extension-scale SSL metadata wrapper Your SpamAssassin installation is misconfigured. Notes inline. On Mon, Sep 21, 2020 at 07:54:29PM +0200, Stefan Hertenberger wrote: > > 0.9 SPF_FAIL SPF: sender does not match SPF record > > 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid > > 0.1 DKIM_INVALID DKIM or DK signature exists, but is not valid These are caused by invalid forwarding confix on a-b.xyz. It needs to strip DKIM and rewrite From: if it's going to behave like this. I suspect but cannot prove that migadu is adding the dkim signatures, which then don't match the Fron: line since 9front.org mail doesn't come from migadu. > > 2.0 FROM_SUSPICIOUS_NTLD_FP From abused NTLD > > 1.3 RDNS_NONE Delivered to internal network by a host with no rDNS > > 0.5 FROM_SUSPICIOUS_NTLD From abused NTLD These are the majority of the weights causing the SPAM tag from SA, and again it's because xyz is a spam hotbed and also because a-b.xyz's IP address reverse-resolves to ten.a-b.xyz. If you intend to continue receiving 9front mail through this domain, it's probably simplest to whitelist the domain in your sa-spamd rules, since nothing sl does to the 9front list will change any of these things. Dropping a 'whitelist_from_rcvd *@9front.org a-b.xyz' into your spamassassin rules may do it, but without seeing the full headers of the as-delivered message I can't be sure. khm