# Amavis lehnt externe Mails ab



## Kaimane (28. Jan. 2017)

Hallo zusammen.
Ich habe ein ISPConfig von 3.1-dev auf die aktuelle Version 3.1.2 upgedatet (Debian, Stretch). Das Update verlief ohne Probleme. Nun wollte ich an dieser Maschine Postfix und Dovecot in Betrieb nehmen. Ich habe eine Maildomain mit dem Spamfilter "Normal" eingerichtet sowie ein entsprechendes Postfach.
Die Mails kommen von extern zwar an, allerdings werden sie von Amavis direkt blockiert und nicht zugestellt.
/var/log/mail.log

```
amavis[7272]: (07272-16) Blocked SPAM {DiscardedInbound,Quarantined}, [...], quarantine: 2/spam-2LUvwAtco8u1.gz, Queue-ID: ECD35BE863, Message-ID: [...], mail_id: 2LUvwAtco8u1, Hits: 0, size: 1232, 422 ms
[...] relay=127.0.0.1[127.0.0.1]:10024, delay=0.75, delays=0.32/0.01/0.01/0.42, dsn=2.7.0, status=sent (250 2.7.0 Ok, discarded, id=07272-16 - spam)
```
Erst, wenn ich in der /etc/amavis/conf.d/50-user

```
$final_spam_destiny = D_PASS;
```
setze, werden die Mails zugestellt, jedoch mit dem Prefix ***SPAM*** im Header, obwohl die Mail ein Spam-Score von 0.8 hat. Ich teste von GMX aus.
Ist jedoch der Mailserver Sender und Empfänger gleichzeitig und die Mail verlässt ihn somit nicht, wird sie ohne Probleme zugestellt. Der interne Versand und die Zustellung klappt demnach, von extern kommende Mails lässt Amavis nicht zu.

Wo ist das Problem am ehesten zu suchen?

Vielen Dank für eure Unterstützung!


----------



## florian030 (28. Jan. 2017)

Wann Amavis Mails als Spam markiert, kannst Du in den Policies für Domain / Mailkonto definieren. Was mit Spam-Mails passiert, definierst Du in Amavis. Ob die Mails verschobene werden, definierst Du pro Mailkonto (move to junk).
Sollte sich das Log auf die Mail beziehen, wo der Du schreibst, sie hätte einen Score von 0.8, dann sieht Dein Amavis das aber doch etwas anders.


----------



## Kaimane (28. Jan. 2017)

Hallo Florian.
Genau, ich hab unter Spamfilter -> "Benutzer / Domain" für die Domain eine Prio von 5 gesetzt und die Richtlinie auf "Normal", welche von ISPConfig mitgeliefert wird. Die Mails werden nicht verschoben, sondern direkt gelöscht. Aber genau, wenn man als Spam markierte Mails direkt in Junk verschieben möchte, setzt man das Häckchen.
Und was den Score betifft, stimmt das so nicht ganz:

```
Received: from localhost (localhost [127.0.0.1])
   by [...] (Postfix) with ESMTP id 1C202BE866
   for [...]; Sat, 28 Jan 2017 02:02:27 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new
X-Spam-Flag: YES
X-Spam-Score: 0.885
X-Spam-Level:
X-Spam-Status: Yes, score=0.885 tagged_above=0 required=0
   tests=[FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.105,
   RCVD_IN_MSPIKE_H2=-0.211, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01]
   autolearn=no autolearn_force=no
```
Das ist ein Auszug aus dem Header der angesprochenen Test-E-Mail.
Der Betreff wird auf ***SPAM*** verändert und würde ohne $final_spam_destiny = D_PASS; gar nicht ankommen.
BTW: die Richtlinie "Normal" hab ich übrigens nicht verändert. Die Werte sind so von ISPConfig übernommen:

```
SPAM Markierungslevel => 1
SPAM Markierungslevel 2 => 4,5
SPAM Markierungslevel kill => 50
SPAM Markierungslevel DSN Cutoff => 0
SPAM Markierungslevel Quarantine Cutoff => 0
```
Und ja, Amavis scheint den Score völlig anders zu interpretieren, als die Schwellenwerte gesetzt sind. Bei einem Score von 0.8 sollte gar nichts passieren. Dennoch wird die Mail ohne Anpassung der Config ungefragt gelöscht.


----------



## Till (30. Jan. 2017)

Versuch mal die normal polcy in ispconfig für die ganze domain zus etzen. Möglicherweise ist die email ja an einen alias gegangen, für den keine andere poslicy gesetzt war.


----------



## Kaimane (30. Jan. 2017)

Die Policy "normal" habe ich schon auf die Maildomain gebunden. Das E-Mail-Konto selber hat keine Spamfilter-Policy und bedient sich somit der Policy der ganzen Domain. Eine Alias-Adresse habe ich aktuell nicht eingerichtet. Nur die Maildomain und das eine Mailkonto. Ich habe das Verhalten ein wenig gegooglet und mal ein

```
sa-update
```
ausgeführt. Nun kommen Mails von GMX, Web.de, etc. an, werden auch nicht fälschlicherweise als Spam markiert oder gar direkt gelöscht. Allerdings habe ich nun Probleme mit eingehenden Mails von anderen Servern, wie z. B. von diesem Forum. Die Benachrichtigung über einen neuen Beitrag wurde als Spam markiert. Ein Auszug aus dem Mail-Header (die interessanten Parts):

```
Received: from localhost (localhost [127.0.0.1])
    by [...] (Postfix) with ESMTP id 45434BEDDE
    for [...]; Mon, 30 Jan 2017 12:51:51 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at [...]
X-Spam-Flag: YES
X-Spam-Score: 0.984
X-Spam-Level:
X-Spam-Status: Yes, score=0.984 tagged_above=0 required=0
    tests=[HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.972, T_REMOTE_IMAGE=0.01,
    URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
```
Nachtrag: ergänzend möchte ich noch darauf hinweisen, der Wert für das "Markierungslevel 2" ist auf 4.5 gesetzt. Die Mail aus dem Forum hat "nur" einen Score von 0.98; dennoch wird die Mail im Betreff als Spam markiert.

Nachtrag 2: Das SPAM-Markierungslevel (erster Wert der Policy) steht auf 1. Die Mail hat jedoch einen Score unter 1. Normalerweise dürften die "X-Spam-..." gar nicht in den Header geschrieben werden ...
Nun die Überlegung, ob die Policy bzw. die Schwellenwerte korrekt aus der DB geladen und verarbeitet werden.
Wie kann man das testen?
Habt ihr noch andere Ansätze, woher die vielen false positives kommen können?


----------



## Kaimane (30. Jan. 2017)

Ein "kurzer" Zwischenstand ...

In der /etc/amavis/conf.d/50-user habe ich $log_level = 4; gesetzt. Das ermöglicht weitestgehend den Prozess von amavis an der eingehenden Mail nachzuverfolgen. Dabei ist aufgefallen, dass die in der /etc/amavis/conf.d/50-user von ISPConfig gesetzten SQL-Statements den richtigen Datensatz aus der DB holt, aber ...

```
Jan 30 20:51:35 s1 amavis[32727]: (32727-05) lookup_sql([...]) matches, result=(id=>"8", sys_userid=>"1", sys_groupid=>"0", sys_perm_user=>"riud", sys_perm_group=>"riud", sys_perm_other=>"r", server_id=>"1", priority=>"10", policy_id=>"5", email=>"[...]", fullname=>"[...]", local=>"Y", id=>"8", sys_userid=>"1", sys_groupid=>"0", sys_perm_user=>"riud", sys_perm_group=>"riud", sys_perm_other=>"r", policy_name=>"Normal", virus_lover=>"N", spam_lover=>"N", banned_files_lover=>"N", bad_header_lover=>"N", bypass_virus_checks=>"N", bypass_spam_checks=>"N", bypass_banned_checks=>"N", bypass_header_checks=>"N", spam_modifies_subj=>"Y", virus_quarantine_to=>-, spam_quarantine_to=>-, banned_quarantine_to=>-, bad_header_quarantine_to=>-, clean_quarantine_to=>-, other_quarantine_to=>-, spam_tag_level=>"0", spam_tag2_level=>"0", spam_kill_level=>"0", spam_dsn_cutoff_level=>"0", spam_quarantine_cutoff_level=>"0", addr_extension_virus=>-, addr_extension_spam=>-, addr_extension_banne...
```
[...] = hidden value

Interessant sind diese Werte aus der DB:

```
spam_tag_level=>"0",
spam_tag2_level=>"0",
spam_kill_level=>"0",
spam_dsn_cutoff_level=>"0",
spam_quarantine_cutoff_level=>"0"
```
Obwohl in der Tabelle spamfilter_policy, Datensatz id=5 (Policy "Normal") die Werte 1, 4.5, 50 (spam_tag_*, spam_kill_level) gesetzt sind, erhält amavis in der DB-Abfrage nur 0-Werte.
Ich habe MariaDB 10.1.21-MariaDB-5 im Einsatz.

Okay, also, ... woran kann es liegen. Die relevanten DB-Felder sind vom Typ "float". Alle DB-Felder, bis auf die "Float"-Felder werden korrekt über das SQL-Statement ausgelesen. Ohne Anhaltspunkt, aber aus dem Bauch, habe ich den Typ der fünf Float-Felder auf den Typ Varchar umgestellt. Im Anschluss wieder eine Testmail von extern verschickt, die immer wieder als Spam erkannt wurde (teilweise mit einem Score von 0.002 :-D) ... Und nun erhalte ich im Log:

```
[...]
spam_tag_level=>"1",
spam_tag2_level=>"4.5",
spam_kill_level=>"50",
spam_dsn_cutoff_level=>"0",
spam_quarantine_cutoff_level=>"0"
[...]
```
Bislang habe ich keine falsch markierten Mails erhalten. Ich werde es weiter beobachten und in ein paar Tagen Feedback geben.


----------



## Till (31. Jan. 2017)

Das ist ja echt merkwürdig, habe ich bislang nicht gesehen das jemand die Felder vom Typ umstellen musste. berichte gern mal, ob es jetzt geht. Aber MySQL und MariaDB haben so vie an Kompatibilität mit Vorversionen über Bord geworfen in der letzten zeit, da wundert mich nichts mehr


----------



## Kaimane (7. Feb. 2017)

Nach gut einer Woche kann ich rückblickend kein Fehlverhalten mehr feststellen. Die Werte werden seit der Umstellung der DB-Feldtypen korrekt ausgelesen und weiterverarbeitet.
Zwischenzeitlich habe ich im Git dies hier gefunden https://git.ispconfig.org/ispconfig/ispconfig3/issues/4499
Liegt es also an Perl, anstatt an MariaDB? Ich habe das nicht weiter verfolgt.
Da meine aktuelle Konfiguration so funktioniert lasse ich diese zunächst wie sie ist und warte auf das nächste ISPConfig-Update, um die Feldtypen entsprechend auf den Decimal-Typ anzugleichen.


----------

