Spam mail passing through

[Amplificator]

I have an issue where some mail that is clearly spam is passing through to the server where I think that a combination of SPF/DMARC/DKIM should have stopped it from even getting through.

The spam is pretending to come from accounts on our domains, such as actual e-mail accounts but also random names, even [email protected] which doesn't actually exist. Also random names with a string of characters, ending in @domain.com passes through.
These e-mails aren't originating from our servers and in the example below, we can also see that they are being received from an IP address of 103.187.24.72 which is not ours.

We have working SPF, DKIM and DMARC for the domains in question so my thinking and the SPF is ending with "-all", so my thinking is that these obvious spam mails shouldn't even get through?

Our SPF looks like this: "v=spf1 a mx include:relay.mailchannels.net -all"

The header of the e-mail is this:

X-Account-Key: account22
X-UIDL: 000000126523dbf7
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
X-Mozilla-Keys:                                                                                 
Return-Path: <[email protected]>
Delivered-To: [email protected]
Received: from RECEIVING.SERVER.COM
    by RECEIVING.SERVER.COM with LMTP
    id kEYMLAm1MGVgGzIAnRjtMw
    (envelope-from <[email protected]>)
    for <[email protected]>; Thu, 19 Oct 2023 06:48:09 +0200
Return-path: <[email protected]>
Envelope-to: [email protected]
Delivery-date: Thu, 19 Oct 2023 06:48:09 +0200
Received: from [103.187.24.72]
    by RECEIVING.SERVER.COM with esmtp (Exim 4.96.2-12-g29d01ae2a)
    (envelope-from <[email protected]>)
    id 1qtKx5-00DrWr-1h
    for [email protected];
    Thu, 19 Oct 2023 06:48:09 +0200
Received: from tjemqbn ([44.105.140.234]) by 32318.com with MailEnable ESMTP; Thu, 19 Oct 2023 10:48:06 +0600
Received: (qmail 96694 invoked by uid 966); 19 Oct 2023 10:48:04 +0600
From: [email protected]
To: [email protected]
Subject: I RECORDED YOU!
Date: Thu, 19 Oct 2023 10:48:06 +0600
Message-ID: <[email protected]>
Mime-Version: 1.0
Content-type: text/plain;

In the above example the RECEIVING.SERVER.COM is our server address and [email protected] is an e-mail lcoated on our server as well. But like I mentioned, we have seen where [email protected] can be anything else and doesn't need to be an actual e-mail, except for the To address.

Am I correct in assuming that a combination of SPF, DKIM and DMARC should block this when the SPF is set to "-all"?
Is there a way to block this obvious spam?

I have a fairly standard setup of DirectAdmin regarding mail. Like I said, SPF, DKIM and DMARC are set up and dkim=1 is set in the DirectAdmin config as well.
mxtoolbox.com reports that this is correct as well.

 

[Amplificator]

It appears to be pretty much the same as in https://forum.directadmin.com/threads/how-to-block-mail-scam-with-own-domains-in-it-but-fake.66222/ but surely there must be a way to block this without having to block IP's all the time?

 

[Richard G]

Yes it's a nuisance at the moment.

Received: from [103.187.24.72] by RECEIVING.SERVER.COM with esmtp (Exim 4.96.2-12-g29d01ae2a)

So this is from Bangladesh.

Then I see this a bit lower:

Received: from tjemqbn ([44.105.140.234]) by 32318.com with MailEnable ESMTP; Thu, 19 Oct 2023 10:48:06 +0600 Received: (qmail 96694 invoked by uid 966); 19 Oct 2023 10:48:04 +0600

This one is from the States. Very odd.

However, I've seen a script which can do this. And it's abused a lot at this moment. We also have this issue on a lot of servers. However, not many of these messages are arriving at customers because we also have the SPF strict and DKIM present, but none of our customers are allowed to have a catch-all email address.
So all attempts from or to non-existing addresses are refused anyway.

Hard to reject, even if you have the SPF strict.

 

[Amplificator]

SpamAssassin does put them in the spam folder though, so it's so it's not the biggest issue but I 'm still wondering how they do this and how to just block it outright, if that's even possible..

 

[Richard G]

It's just plain spoofing. You can find scripts out there to do it. And by accessing your mailserver and sending from there it isn't refused.

I'm also wondering... there should be a way to build in a check so an MTA sees if some "from" mail is coming from an account on the server and then block it because that account doesn't have used smtp authentication to send mail "from" it.
There is a helo/ehlo check too and then you get a "host impersonating domain name". Would be nice to have something similar for e-mail addresses if indeed possible. But I doubt it.