Installationsempfehlung

ivenae

Well-Known Member
Feb 11, 2022
119
45
48
42
Ich habe mich in den letzten Tagen intensiv mit Proxmox MG beschäftigt und fand die Anleitung nicht immer hilfreich.
Mein Spam wird um 90% reduziert, dabei möchte ich hier erklären, was ich ggü. der Out of the Box Installation verändert habe, um das zu erreichen. Das ist aus meiner Sicht etwas, was in vielen Anleitungen zu kurz kommt.
Danke an das Proxmox Team für dieses hervorragende Produkt und danke an alle, auf deren Kommentare und Empfehlungen hin ich Dinge umgesetzt habe. Kommentieren erwünscht, wenn euch dieser Beitrag gefällt, lasst mir ein Abo und ein Like ... Spaß.

Ich setze selbst einen Proxmox LXC im gleichen Netz ein, auf dem Modoboa als Mailserver läuft.

Meine Politik dabei ist, dass E-Mails gar nicht erst angenommen werden, wenn sie Spam sind, denn das größte Übel ist aus meiner Sicht, dass false positives, die in meinem Spam Ordner untergehen vom Sender als zugestellt geglaubt werden. Das schützt natürlich nicht davor, wenn bestellte Konzertkarten o.ä. bei mir nicht ankommen, weil der Absender seinen Mailserver nicht im Griff hat. Die Konzertkarten sind dann vermutlich 'weg' und erfordern erhebliche Nacharbeit. Ein Manko von "ich nehme deinen Kram nicht an".

Konsole: Unbound installieren
apt install unbound
127.0.0.1 in die /etc/resolv.conf eintragen (bei LXC Containern: Über Proxmox VE in den DNS Optionen setzen)
# Damit die DNSBL vernünftig funktionieren


Configurations -> Mail Proxy -> Relay Domains:
Eintragen meiner Domains
# E-Mails, die an diese Domains gehen, werden von Proxmox überhaupt aktzeptiert


Configurations -> Mail Proxy -> Options:
Verify Receivers: Yes (550)
# Sicherstellung, dass E-Mails an unbekannte Mailkonten gar nicht erst angenommen werden. Ansonsten gibt es Bounces von Modoboa zum Proxmox, die beim Proxmox verbleiben, von denen der Versender jedoch nichts erfährt.

Use Greylisting for IPv4: No
# Greylisting verzögert die Annahme teilweise erheblich, was sehr schlecht bei Kontoverifizierungs E-Mails ist. Möchte ich nicht und bringt auf Basis meiner (bisher kurzen) Erfahrung keinen erheblichen Mehrwert

Before Queue Filtering: Yes
# Kernanliegen, denn nachträgliche "NDRs on Blocked E-Mails" sind selbst Spam.

DNSBL Sites:
<ID>.zen.dq.spamhaus.net
# Bei Spamhaus registrieren und individuellen Link einfügen. Nicht den offenen zen.spamhaus.org nutzen.
b.barracudacentral.org
# Hier ist aktuell keine Registrierung möglich, soweit ich das sehe. Irgendwann muss das nachgeholt werden


Configurations -> Mail Proxy -> Transports:
Eintragen meines Mailservers
<domain> -> Host: 172.30.0.3, use MX: No
# MX: No -> Weil der MX auf das PMG zeigt


Configurations -> Spam Detector -> Options:
Use Bayesian filter: No
# Bringt kaum Mehrwert für mich

Use RBL checks: Yes
# Dafür haben wir die DNSBL eingetragen

Use Razor2 checks: Yes
# Scheint viel zu bringen


Mail Filter-> What Objects:
Spam Level 10 -> ändern auf Spam Level 6
Spam Level 3 -> ändern auf Spam Level 4
# Sehr individuelle Entscheidung, ich möchte Spam ab Level 6 bereits nicht mehr akzeptieren


Mail Filter:
Block Spam (Level 10): Umbenennen in Level 6 und prüfen, ob hier als What Object der Level 6 Spam steht

Quarantine Spam (Level 6): Regel Deaktivieren. Ich möchte keine Quarantäne. Ganz oder gar nicht

Mark Spam (Level 3): Umbenennen in Level 4:
Action Object: Modify Spam Subject (Kein Notify, kein Qurantine)
What Object: Spam (Level 4)

# Ganz oder gar nicht:
# Ab Level 6 Blocken (durch Before Queue Filter wird rejected)
# Ab Level 4 mit Spam Tag (ggf. durch Modoboa in Spam Ordner einsortieren)
# keine Quarantäne in einem Level dazwischen
# Hier handelt es sich sicherlich um eine sehr individuelle Entscheidung


#####Nun auf die Konsole wechseln:
Transportliste als gültige Empfänger:

Folgendes Skript erstellen, welches täglich die Transportliste nutzt, um 'BCC'-Spam auszusortieren. Das ist für mich Spam, der dadurch klassifiziert wird, dass ich nicht als Empfänger oder CC-Empfänger bin, sondern nur in einer BCC-Liste stehe. Alle E-Mails, in denen die Domains der Transportliste nicht in der Empfängerliste stehen, bekommen einen Scorepunkt. Achtung: Wer in Mailinglisten unterwegs ist, könnte hiermit Probleme bekommen und muss diese ggf. Whitelisten. Auch Weiterleitungen von Free-Mail-Accounts an die eigene Domain sind hiervon betroffen. Ggf. diese Whitelisten. ChatGPT hat tatsächlich bei diesem Skript ganze Arbeit geleistet und mir das mehr oder weniger so ausgespuckt.

~# cat > /usr/local/bin/update-sa-bcc-whitelist.sh
Code:
#!/bin/bash
DOMAINS=$(cut -d' ' -f1 /etc/pmg/transport | sed 's/\./\\./g; s/-/\\-/g' | tr '\n' '|' | sed 's/|$//')

cat <<EOF > /etc/mail/spamassassin/98-bcc-transport-domains.cf
header   BCC_SPAM_TOCC ToCc !~ /\@(${DOMAINS})/i
score    BCC_SPAM_TOCC 2.0
describe BCC_SPAM_TOCC Domain nicht in Transport-Liste
EOF
sa-compile
systemctl restart pmg-smtp-filter


Skript als ausführbar markieren und einmalig ausführen:
chmod +x /usr/local/bin/update-sa-bcc-whitelist.sh
/usr/local/bin/update-sa-bcc-whitelist.sh

Cron Eintrag für die tägliche Aktualisierung dieser Liste
echo "0 0 * * 1 root /usr/local/bin/update-sa-bcc-whitelist.sh" > /etc/cron.d/sa-bcc-update


### Custom Rules in /etc/mail/spamassassin
# Die Regel 98-bcc-transport-domains.cf sollte nun schon existieren

Regel zum erweiterten Markieren von BCC Spam
Diese Regel besteht aus 4 Teilen
Teil 1: Markiert alle E-Mails von einer beliebigen TLD, vergibt jedoch keinen Score
Teil 2: Markiert alle E-Mails von seriösen TLDs. Die Liste kann von euch erweitert werden. Bei mir sind seriös: com, net, org, de, at, ch, eu, shop
Teil 3: Markiert alle E-Mails, die in Liste 1, jedoch nicht in Liste 2 sind, also von _allen anderen_ Domains stammen (com.tr, pl, ru, sbs, ...)
Diese erhalten automatisch einen Score von 2.0, weil sie nahezu immer unseriös sind
Teil 4: Wenn die E-Mail von einer unseriösen TLD stammt, und ich zusätzlich nur im BCC stehe, dann wird ein weiterer "Bonus"-Score von 1.0 vergeben.
E-Mails die dieses Kriterium erfüllen sind fast immer Spam, Ausnahmen könnten ausländische Mailinglisten sein. Die müsste man in die Welcomelist eintragen.
Aber: Wenn alle anderen Kriterien nicht negativ sind, führen diese Kriterien zwar zu einem hohen Score, aber alleine noch nicht zu einem Block (2 + 2 + 1 = 5, Block ab 6)

Code:
cat <<EOF > /etc/mail/spamassassin/99-BCC_TLD.cf
header FROM_TLD_OTHER From =~ /\.(?!(?:com|net|info|org|de|at|ch|eu|shop)(?:>|$))[A-Za-z0-9-]+>?$/i
score FROM_TLD_OTHER 3.0
describe FROM_TLD_OTHER Sender uses unusual or risky TLD

meta BCC_AND_UNKNOWN_TLD (FROM_TLD_OTHER && BCC_SPAM_TOCC)
score BCC_AND_UNKNOWN_TLD 2.0
describe awkward sender and unknown recipient


"Don't be evil": 80% aller Spams von Google
Google ist bei mir für 80% des Spams [sic!] verantwortlich.

firebaseapp.com (Google Service) verschickt mehr oder weniger ausschließlich Spam und erhält "Bonuspunkte".

Spammer nutzen mittlerweile selbst angelegte Google Groups Listen, weil sie kein Opt-In des Empfängers benötigen und Mailinglisten standardmäßig seitens Spamassassin einen Score von "-1.0" zugewiesen bekommen. Nicht nur die Spam-Mails kommen an, sondern auch die Auto-Replys der anderen Empfänger oder die wütenden "Nehmt mich da raus" Antworten. Daher bekommen Google Mailing-Lists einen Score von 5 (+ 1.0 für BCC -1.0 für Spam-Assassin Mailing Default). Dadurch landen 95% aller Google Mailinglisten im Block/reject, außer die "positive Word List" greift mal versehentlich.

Und zuguterletzt: Google wird (leider) mittlerweile von einigen großen Unternehmen (Doctolib, Ryanair) im Rahmen des Google Workplace als Versender von E-Mails eingesetzt. Wer also seine Flugtickets weiterhin erhalten will, kann leider Google nicht gänzlich blockieren (erste Ideen des Filters basieren darauf, nichts von Google zu akzeptieren, was nicht als Absender googlemail.com, gmail.com, google.com oder google.de beinhaltet). Aber es ist wirksam, saftige Strafpunkte zu verteilen, sofern die Domainendung nicht aus obiger TLD-Liste ist (.com, .de, .at, ...), wenn die E-Mail von Google verschickt wurde. Achtung: Hier addieren sich ggf. Punkte verschiedener Kategorien, ist aber aufgrund der unglaublichen Schwemme an Müll seitens der Google Server zu verschmerzen.

Code:
header FROM_FIREBASEAPP From =~ /firebaseapp\.com>?$/i
score  FROM_FIREBASEAPP 7.0
describe FROM_FIREBASEAPP firebase only send spam

header GOOGLE_GROUPS List-Unsubscribe =~ /googlegroups\.com/i
score  GOOGLE_GROUPS 7.0
describe GOOGLE_GROUPS Block Google Groups mailing lists

header   __HELO_GOOGLE   Received =~ /\.google\.com/i
meta     GOOGLE_FROMTLD_OTHER  (__HELO_GOOGLE && FROM_TLD_OTHER)
score    GOOGLE_FROMTLD_OTHER  3.0
describe GOOGLE_FROMTLD_OTHER  HELO endet auf google.com und FROM_TLD_OTHER trifft zu

Positive Word List
Diese Regel(n) beinhalten Wörter, die i.d.R. darauf hindeuten, dass es sich um seriöse E-Mails handelt (z.B. Bestellbestätigungen)
Hier bitte <meine Stadt> durch euren Wohnort ersetzen und <mein Name> durch euren Vornamen
-9.0 Score gibt es für die Erwähnung meiner Stadt in der E-Mail, oft handelt es sich dann um Bestellbestätigungen etc. Das möchte ich immer erhalten

-5.0 Score gibt es für die Erwähnung meines Vornamens. Meist ist das ebenfalls ein Hinweis darauf, dass der Empfänger mich persönlich kennt.
Achtung: Die Regel führt ggf. zu Problemen, wenn euer Vorname in eurer E-Mail vorkommt, denn dann kommen generische Mails auch durch wie:
"Hallo vorname.nachname@domain.example, sie haben ggf. auch Probleme mit ihrer Potenz"

Diese Liste könnt ihr natürlich beliebig erweitern, um z.B. eure Straße oder sonstige, individuellen Wörter. Ich habe hier noch das Wort "Ticket" mit drin.
Hinweis dazu: Schreibt ihr mehrere Wörter in eine Regel, dann wird beim Auffinden mehrerer Wörter nur einmal der Score abgezogen. Schreibt ihr mehrere Wörter in mehrere Regeln, dann werden beim Auffinden mehrerer Wörter der Score mehrmals abgezogen. Beides kann sinnvoll sein.

Ihr könnt damit herumspielen, indem ihr \b einsetzt, welches dafür sorgt, dass das Wort von Leerzeichen umgeben sein muss. (Greift dann auf <Vorname>, aber nicht auf <vorname.nachname@..>

Außerdem sorgt das i am Ende dafür, dass Groß- und Kleinschreibung egal ist. Auch damit kann man "herumspielen".

Code:
cat <<EOF > /etc/mail/spamassassin/99-positive-word-list
body POSITIVE_WORDS_HIGH /<meine Stadt>/i
score POSITIVE_WORDS_HIGH -9.0
describe POSITIVE_WORDS_HIGH Enthält vertrauenswürdige Wörter

body POSITIVE_WORDS_LOW /<mein Vorname>/i
score POSITIVE_WORDS_LOW -5.0
describe POSITIVE_WORDS_LOW Enthält vertrauenswürdige Wörter
EOF


Filter kompilieren
Damit die Filter schneller abgearbeitet werden, sollten sie kompiliert werden. Wir benötigen hierzu ein paar Pakete:

Code:
apt get install make gcc re2c

Danach kompilieren und am Ende Spamassassin neustarten mit:
Code:
sa-compile
systemctl restart pmg-smtp-filter


Fazit
Die Quote der falsch positiven liegt bei < 0,5%, insgesamt betraf das 2 E-Mails:
- In einem Fall hatte der Absender sein DKIM falsch konfiguriert, deshalb hatte eine seriöse E-Mail einen Score von 6.0, wobei 3.0 vom falschen DKIM beigesteuert wurde.
- In einem Fall wurde eine Domain Verifizierungs E-Mail an eine E-Mail Adresse geschickt, die ich nur per Weiterleitung bekomme. Dadurch hatte die Mail einen Basis-Score von 2.0 und aufgrund anderer, unglücklicher Eigenschaften kamen auch hier insgesamt 6.0 als Score heraus. Die E-Mail konnte einfach neu beantragt werden, der Filter wurde dann kurzzeitig komplett deaktiviert.

Spamscores in 14 Tagen:
Score 0: 80%
Score 1-3: 5%
Score 4-5: 2 % (Spam Tag)
Score 6-9: 3 % (Block)
Score 10++ : 10% (Block)

Achtung, traue keiner Statistik, die du nicht selbst gefälscht hast:

- geschätzt 1/3 aller Score 0 E-Mails sind ausgehende E-Mails. Die werden nicht gescannt, tauchen aber in der Statistik auf.

- Als IT-ler bekomme ich viele Status E-Mails von Kunden. Diese werden per Smarthost an mich geleitet, wobei der Smarthost mein eigener Mailserver ist. Die E-Mails tauchen in der Liste auch nicht auf, weil sie direkt von meinem Mailserver einsortiert werden und nicht über das PMG gehen.

- Ca. weitere 10% (hää? Das sind ja dann 110%!!!) wurden aufgrund von Spamhaus.net rejected, d.h. hier wurde die Verbindung mit dem E-Mail Server direkt abgelehnt. Die Mails bekommen gar keinen Score und tauchen auch nicht in der Liste auf, wären aber ohne PMG vermutlich zugestellt worden.

- Darüber hinaus gibt es eine Vielzahl an Servern, die mein System auf Open-Relay testen (spameri@tiscali.it; relaycheck_please_ignore@protonmail.com) , d.h. der Empfänger liegt nicht auf meinem Mailserver; oder der Empfänger ist ein ungültiges E-Mail Postfach auf meinem Mailserver. Die E-Mails tauchen teilweise in der Statisik auf, hätten aber mein eigenes Postfach gar nicht betroffen.

Trotzdem ist die Statistik ein gutes Indiz.


Wer weniger Risiko möchte, schaltet den Block erst ab Score 10 scharf.
 
Last edited:
Kurzer Nachtrag, sofern man keinen eigenen Mailserver betreiben möchte:
Mit All-Inkl. als Mailanbieter habe ich die Konfiguration laufen. Folgendes muss beachtet werden:

- Als Relay trägt man den eigenen kasserver ein, Port 25, kein MX benutzen

- Bei All-Inkl. im DNS erstellt man einen "Sandwitch"-MX: Zwei verschiedene Domainnamen für den eigenen Proxmox PMG Server mit niedrigster und höchster Priorität (z.B. 5 und 15). Eigentlich möchte man hier zweimal den gleichen Eintrag erstellen, einmal mit Prio 5 und einmal mit Prio 15. Das mag All-Inkl. jedoch nicht, daher setzt man hier zwei unterschiedliche FQDN für die gleiche IP; alternativ einmal den FQDN und einmal die IP.

- Wichtig: In der Mitte des Sandwitches bleibt der kasserver als MX (default Prio 10).
Warum das?
Der All-Inkl. Server fühlt sich nach einigen Stunden nicht mehr zuständig, wenn er nicht einen MX Record besitzt und lehnt Mails ab mit "relay access denied", es muss demnach einen MX Eintrag für den kasserver geben. Wir lassen ihn unangetastet.
Üblicherweise versenden Mailserver an den MX mit der niedrigsten Prio, einige Spammer nutzen das aus und schicken an den mit der höchsten Prio in der Hoffnung dort weniger Gegenwehr zu erhalten. Daher setzen wir unseren kasserver in die Mitte, dann bleibt er i.d.R. verschont.

- In jeder angelegten E-Mail Adresse [sic!] muss einmalig der policyd weight Filter ausgeschaltet werden, damit keine SPF Prüfungen durchgeführt werden. Mit SPF Prüfung landen i.d.R. alle eingehenden E-Mails im Spam.
 
Last edited: