E-Mail Spam: To != Envelope-to

Good morning!

At the moment I receive about 10 spam emails every night. These are not automatically recognized as spam and marked accordingly.

The special thing in this case is that the “Envelope-to” sender and the “To” sender are different:

Return-path: <[email protected]>
Envelope-to: [email protected]    // <----- here
Delivery-date: Wed, 02 Feb 2022 00:23:02 +0100
Received: from mail.minstellor.ru ([62.173.138.102])
    by ******** with esmtp (Exim 4.94.2)
    (envelope-from <[email protected]>)
    id 1nF2UF-009hAP-LP
    for [email protected]; Wed, 02 Feb 2022 00:23:02 +0100
Received: from minstellor.ru (eub.knomo.site [91.215.171.72])
    by mail.minstellor.ru (Postfix) with ESMTPA id 5484983559;
    Wed, 2 Feb 2022 00:48:13 +0200 (EET)
Reply-To: "Christine Heidecker" <[email protected]>
From: "Christine Heidecker" <[email protected]>
To: <[email protected]>    // <----- and here
Subject: card with high credit line despite bad bank report is feasible

As a note: I have set up a catch-all on my domain.

Question: why are these emails not marked as spam or rejected outright?


Spam Header

X-Spam-Score: 19
X-Spam-Bar: +
X-Spam-Report: Spam detection software, running on the system "my-server.com",
    has NOT identified this incoming email as spam. The original
    message has been attached to this so you can view it or label
    similar future email. If you have any questions, see
    @@CONTACT_ADDRESS@@ for details.
    Content preview: Karte mit hohem Kreditrahmen trotz schlechter Bankauskunft
    ist machbar &gt;&gt;&gt; Karte mit hohem Kreditrahmen trotz schlechter Bankauskunft
    ist machbar >>>
    Content analysis details: (1.9 points, 5.0 required)
    pts rule name description
    ---- ---------------------- --------------------------------------------------
    0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was
    blocked. See
    http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
    for more information.
    [URIs: vitelaner.today]
    -0.0 SPF_PASS SPF: sender matches SPF record
    -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
    0.0 T_TVD_MIME_EPI BODY: No description available.
    0.0 HTML_MESSAGE BODY: HTML included in message
    0.0 HTML_IMAGE_RATIO_02 BODY: HTML has a low ratio of text to image
    area
    1.8 HTML_IMAGE_ONLY_08 BODY: HTML: images with 400-800 bytes of
    words
    0.1 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image
X-redirected: yes

EDIT: Does the line need to be commented out? (SPAMASSASSIN)

#   Set the threshold at which a message is considered spam (default: 5.0)
#
# required_score 5.0

Spam score is set in exim:
hestiacp/exim4.conf.4.94.template at 83cfa9804d3346b42fa879ed6f40f7366767b904 · hestiacp/hestiacp · GitHub (When spamassing is active it # should be removed…)

Where 5.0 = 50

Base score: 19 is smaller then 50 (default)

Why envelope-to and to is not matched no idea …

I changed the spam_score value to 30 and wait until tomorrow morning.

spamassing is active. Current config file head:

######################################################################
#                                                                    #
#          Exim configuration file for Hestia Control Panel          #
#                                                                    #
######################################################################

SPAMASSASSIN = yes
SPAM_SCORE = 30
CLAMD = yes

smtp_banner = $smtp_active_hostname

So I will search a little bit about envelope-to and to.

It’s quite common actually (eg when you’re Bcc’ed). Just as EnvelopeFrom and From often don’t match (which is often encountered in malicious mails).

Also check the comments at

If one were only going to use IMAP (no POP3 users), then one could avoid rewriting the subject (adding *** SPAM ***) and just filter spam into a folder instead.

PS: HestiaCP’s mail sub-system could use some love :smiley:

2 Likes

Love is not free.

1 Like

Love is free. How ever the time that needs to be spend on it not…

1 Like

It’s quite common actually (eg when you’re Bcc’ed). Just as EnvelopeFrom and From often don’t match (which is often encountered in malicious mails).

I have not considered the BCC recipient at all. That makes sense, of course!

Of course being in BCC should increase the spam score and if the To header is empty showing undisclosed recipients then it should get extra points.

How can we tune that? Does it make sense to deploy that with hestia? (It does to me)

BTW: After changing the spam score: it works very well:

grafik

Excuse my ignorance but, by reducing the spam score to 30 you are increasing the chances of getting false positives instead you could just increase the spam score when certain conditions are met such as being in BCC.

Is that how we should do it?

Should explain it.

Of course I understand that.

I was asking if there is a preferred method to assign new rules to Spam assassin to increase the spam score of messages with BCC all users and I was saying that maybe it was not wise to lower the spam threshold to 30.

Isn’t this the default now? I already wondered why I got a SPAM in my inbox today. Geez. I wonder why people are still spending so much time with this. You just move your spam-score threshold to 5.6 and then have all spam dropped in Junk (not Spam) and force your users to use IMAP. I’ve been running our mailservers for the last 15 years with that setting, and have had no complaints. Just be sure you update your spamassassin rules every now and then.

Also, I noticed a INBOX.Spam folder was created. This should not be there:

cat /etc/dovecot/sieve/default
require ["fileinto"];
# rule:[SPAM]
if header :contains "X-Spam-Flag" "YES" {
    fileinto "INBOX.Spam";
}

it needs to be changed into

require ["fileinto"];
# rule:[SPAM]
if header :contains "X-Spam-Flag" "YES" {
    fileinto "INBOX.Junk";
}

because in dovecot config you also do this;

namespace {
    mailbox Spam {
        auto = subscribe
        special_use = \Junk
    }
    mailbox Junk {
        auto = subscribe
        special_use = \Junk
    }

or at least that is how it is configured where I live.