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

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 'yellow@noreply.github.com'
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

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


 URIBL_ABUSE_SURBL,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0
X-Original-To: me@myadress.tld.de
Delivered-To: me@myadress.tld.de
Received: by my.provider.tld (Postfix, from userid 30)

 id 00EA61784E4A; Tue, 31 Jul 2018 09:02:10 +0200 (CEST)
X-Original-To: me@myadress.tld
Delivered-To: me@myadress.tld
Received: from mx06.ispgateway.de (mx06.ispgateway.de [])
 by my.provider.tld (Postfix) with ESMTPS id A11D51784E48
 for ; Tue, 31 Jul 2018 09:02:04 +0200 (CEST)
Authentication-Results: servername; dkim=none header.i=info@dbc-mail.net;

 dkim=none header.i=SRS0=BtJQ=KP=dbc-mail.net=info@no-si.de;
 spf=fail (sender IP is smtp.mailfrom=info@dbc-mail.net
Received-SPF: fail (servername: domain of dbc-mail.net does not designate
 as permitted sender) client-ip=; envelope-from=info@dbc-mail.net;
X-Envelope-to: alias@redirection.tld
Received: from [] (helo=dbc-mail.net)
 by mx06.ispgateway.de with esmtp (Exim 4.90_1)
 (envelope-from ) id 1fkOfT-0006mC-RK
 for alias@redirection.tld; Tue, 31 Jul 2018 09:02:04 +0200
To: alias@redirection.tld
From: Andreas Nimmerfall 
Subject: Nachricht
Date: Tue, 31 Jul 2018 00:02:03 -0700
Message-ID: <20180731_070203_068931.info@dbc-mail.net>
X-Mailer: MS Outlook
Content-Transfer-Encoding: 8bit
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0
X-ACL-Warn: 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 as permitted sender )
X-PPP-Message-ID: <20180731070209.17663.6754@my.provider.tld>
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


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:


Andreas Nimmerfall
GLB - Contact-Team.

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

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.

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.