Re: *****SPAM***** [9front] test

[Kurt H Maier <khm@sciops.net>]

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