emClient (V7.1.33101.0) filters e-mail as junk that does not match any filter rule

NoSi1 · August 1, 2018, 5:29pm

My Filter Rules

I am using only local POP3/SMTP post boxes.

In the following I extracted ALL rules of my emClient
The matched e-mail is junk. It is moved – like nearly all e-mails – to junk. But I do not see a rule saying that.
The UTF-8 encoded mail is displayed currupted in source code. German umlauts are shown as “??”

The following list has filterted the example e-mail to junk. Meanwhile I tried switching Blacklist, Spam, and other filters on/off. As far as I can say, the only option is no rules because only then there is no unwanted junking.

My Filter Rules

After message has been received
with 'from:amazon.de', 'from:amazon.com' found in header
move to Amazon
and stop processing other rules
except with 'SPAM' found in subject


After message has been received
with 'from: @paypal.de' found in header
move to PayPal
and stop processing other rules
except with 'SPAM' found in subject


After message has been received
sent to '[email protected]'
move to Yellow
and stop processing other rules

After message has been received
with 'Nagelpilz', 'Dating', 'Sex', 'Christmas Sales', 'Sale', 'Potenz', 'Pille', 'Potenzpillen' found in subject
move to Junk E-mail
and stop processing other rules


After message has been received
with 'SPAM' found in subject
move to Junk E-mail
and mark as read
and stop processing other rules
and set categories 'JUNK'


After message has been received
with 'X-Spam-Status: Yes' found in header
move to Junk E-mail
and stop processing other rules

Blacklist has no entries

Standard-spam filter is off.

The filtered mail

Return-Path: 
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on my.provider.tld
X-Spam-Level:
X-Spam-Status: No, score=0.7 required=6.0 tests=BAYES_00,


 HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_RP_RNBL,T_FILL_THIS_FORM_SHORT,


 URIBL_ABUSE_SURBL,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: by my.provider.tld (Postfix, from userid 30)


 id 00EA61784E4A; Tue, 31 Jul 2018 09:02:10 +0200 (CEST)
X-Original-To: [email protected]
Delivered-To: [email protected]
Received: from mx06.ispgateway.de (mx06.ispgateway.de [80.67.18.6])
 by my.provider.tld (Postfix) with ESMTPS id A11D51784E48
 for ; Tue, 31 Jul 2018 09:02:04 +0200 (CEST)
Authentication-Results: servername; dkim=none [email protected];


 dkim=none [email protected];
 spf=fail (sender IP is 80.67.18.6) [email protected]
 smtp.helo=mx06.ispgateway.de
Received-SPF: fail (servername: domain of dbc-mail.net does not designate 80.67.18.6
 as permitted sender) client-ip=80.67.18.6; [email protected];
 helo=mx06.ispgateway.de;
X-Envelope-to: [email protected]
Received: from [209.220.160.246] (helo=dbc-mail.net)
 by mx06.ispgateway.de with esmtp (Exim 4.90_1)
 (envelope-from ) id 1fkOfT-0006mC-RK
 for [email protected]; Tue, 31 Jul 2018 09:02:04 +0200
To: [email protected]
From: Andreas Nimmerfall 
Subject: Nachricht
Date: Tue, 31 Jul 2018 00:02:03 -0700
Message-ID: <[email protected]>
X-Mailer: MS Outlook
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
X-ACL-Warn: 209.220.160.246 is not allowed to send mail from dbc-mail.net.
 Help at/Hilfe unter www.mfaq.info
X-Received-SPF: fail ( mx06.ispgateway.de: domain of dbc-mail.net does not
 designate 209.220.160.246 as permitted sender )
X-PPP-Message-ID: <[email protected]>
X-PPP-Vhost: myadress.tld

Sehr geehrte Damen und Herren,

nach unserem Besuch Ihrer Homepage m??chten wir Ihnen ein Angebot von Produkten vorstellen, das Ihnen erm??glichen wird, den Verkauf Ihrer Produkte sowie Dienstleistungen deutlich zu erh??hen.

Unser Angebot beinhaltet Datenbanken mit den Adressen deutscher Firmen, respektive potentiellen Kunden f??r Ihr Unternehmen.

Die Datenbanken der Firmen sind in f??r Sie interessante und relevante Zielgruppen untergliedert.

Die Firmenangaben beinhalten:

Firmennamen, Adresse des Hauptsitzes (Stra??e und Hausnummer, Postleitzahl, Ort, Region), E-Mail-Adresse, Telefonnummer, Faxnummer.


*** DE - Firmenadressen 2018 ( 1 457 620 ) - 190,- ??? - bis zum 31.07.2018


http://www.kontakt-dbs.net/?page=catalog

Die Verwendungsm??glichkeiten der Datenbanken sind praktisch unbegrenzt und Sie k??nnen durch Verwendung
der von uns entwickelten Programme des personalisierten Versendens von Angeboten u.??. mittels
E-mailing bzw. Fax effektive und sichere Werbekampagnen damit durchf??hren.

Bitte informieren Sie sich ??ber die weiteren Details einmal unverbindlich auf unseren Webseite:

http://www.kontakt-dbs.net/?page=catalog

MfG
Andreas Nimmerfall
GLB - Contact-Team.

Gary · August 7, 2018, 2:14pm

NoSi, does this only happen with 7.1.33101, or is it happening with the previous versions also?

NoSi1 · August 8, 2018, 6:33am

Spam and blacklist filtering never worked satisfying but with the latest version it is useless.

Deleting the standard filter for blacklist and spam, the filtering to folders seem to work as expected, but I am currently not sure. And these are “simple” filter for a dedicated adress. No filtering of matches in (source) content – this do not work anyway as far as I can see at the moment.

Gary · August 8, 2018, 6:50am

In my experience Blacklist is just another Rule, with move messages from address/domain to Junk. If you have the wrong criteria, it is not going to work, but it has always worked perfectly for me, even when there have been other Rules issues. Instances where it won’t work is where the domain or address of the spam messages has changed, which is a common practice among spammers. Good spammers never send from the same address twice.

The Spam filter Rule is only as good as your email server. If the server has added the header, this Rule will move the message. I did notice that you disabled the default one, and added your own which does not contain both arguments that are n the original. Of course if your server is adding a non-standard header for spam, then this one will not work out of the box. If your server is not adding the spam headers at all, then this Rule will not work, at all.

I never experienced problems with these two when using 7.1.33101. One difference between our Rules is that I never use the stop processing other Rules argument. My initial thought on that was that it did just that, stopped processing all Rules on all messages. Not that it stopped processing other Rules just on this message. I may be totally wrong on that one, but without that argument, my Rules work just fine on POP3.