From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from wopr.sciops.net ([216.126.196.60]) by ewsd; Mon Sep 21 21:04:41 EDT 2020 Received: (qmail 65143 invoked by uid 1001); 21 Sep 2020 18:04:33 -0700 Date: Mon, 21 Sep 2020 18:04:33 -0700 From: Kurt H Maier To: 9front@9front.org Subject: Re: *****SPAM***** [9front] test Message-ID: <20200922010433.GG43872@wopr> Mail-Followup-To: 9front@9front.org References: <20200921215743.GF43872@wopr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: private agile singleton markup On Tue, Sep 22, 2020 at 12:32:38AM +0200, kvik@a-b.xyz wrote: > > What's confusing to me is how any of my systems, ten.a-b.xyz in > particular, come into this picture -- they have no part in the mail > business. Some server, I don't know which, is identifying to some other server as 'a-b.xyz' and this is where the problem starts. I suspect but cannot know that this may be migadu's service masquerading as your domain for purposes of mail deliverability, but it might just be some server along the chain setting a fucked-up header and subsequent systems getting mad at that header. Anyway, once Mystery Asshole identifies as a-b.xyz, the receiving server, in this case vbsd.alarum.de, looks at the IP making this claim. We don't know what IP that might be because we don't have access to headers or logs. Regardless, it wants to check that the host sending from this IP and claiming to be a-b.xyz is in fact a-b.xyz, so it does a reverse DNS lookup on that address, which comes up empty. SpamAssassin grumply assigns the message an RDNS_NONE label with a spam weight of 1.3 and continues processing. We cannot know from available data whether this SpamAssassin evaluation is occurring during the SMTP handshake, or if that handshake is happening and then headers are being set for SpamAssassin to get mad at. If it's the latter, it's possible that something is munging those headers before SpamAssassin gets its hands on the message. However: even if it had looked up rDNS of an ACTUAL connection from a machine that REALLY IS a-b.xyz, it still would have failed. a-b.xyz resolves to 178.63.42.176. rDNS for that address is 'ten.a-b.xyz' -- which means even if everything else were on the level, this test would still have failed (albeit with a different rule violation). Generally speaking, a lot of these kinds of errors occur when someone has put SpamAssassin too late in the incoming-mail processing pipeline, which can cause it to process all kinds of headers that MDAs should care about and SpamAssassin should not. For instance, if an MTA receives a message, and hands it off to the MDA, and the MDA is configured to bounce that mail to another MTA, you wind up with really weird headers that occur twice or don't match up with other headers, sometimes leading to RFC violations, which the secondary MTA runs through SpamAssassin, marks as spam, then hands off to an MDA. In other words, that SpamAssassin instance is misconfigured. Exactly how is a fun detective puzzle where we have to extrapolate from absent logs and headers. khm