IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Schlagwort: SelfHosted (Seite 6 von 6)

AMaViS Performance-Tuning

Ich beobachte in der letzten Zeit immer mal wieder dass E-Mails im AMaViS lange hängen bleiben…. Viel Zeit scheint dabei für die Festplatte bzw. die Schreib-/Lesezugriffe drauf zu gehen. Die E-Mail wird von AMaViS angenommen, in dessen tmp Verzeichnis geschrieben. Dann noch ein paar mal gelesen um alle Tests zu machen, ausgepackt usw. usw… Um dieses etwas einzugrenzen habe ich mich gedacht, warum nicht eine RAM Disk für AMaViS oder besser für dessen Temp?

Auf einer gängigen Debian Kiste findet sich dieses Verzeichnis hier:

/var/lib/amavis/tmp

 Damit dieses Verzeichnis nicht mehr auf der Festplatte herum-gewürfelt wird, sondern sich nur noch im Arbeitsspeicher des Servers befinden (der ist ja viel schneller als so ne olle HDD) trägt man folgendes in seine /etc/fstab ein:

/dev/shm    /var/lib/amavis/tmp    tmpfs    defaults,size=256m,mode=750,uid=109,gid=113    0 0

 Man sollte nur darauf achten, dass uid und gid die des lokalen amavis sind. Sonst darf am Ende AMaViS nicht mehr in ein eigenes Temp schreiben. Es soll bessere Wege die ID zu finden, ich mache es schnell und einfach mit:

$ cat /etc/passwd|grep amavis
amavis:x:109:113:AMaViS system user,,,:/var/lib/amavis:/bin/sh

109 ist dabei die User-ID
113 ist die Group-ID

 Das neue AMaViS-tmp ist damit 256MB gross. Für die Grösse gibt es eine „Faustformel“… Diese macht nicht für jeden Sinn! Man würde mit dieser Formel zwar _fast_ nie in die Gefahr eines zu kleinen AMaViS-temps laufen, nur verbrennt man so seinen RAM. Try and Error ist hier eher mein Vorschlag. Denn sollte AMaViS wirklich mal keinen Platz mehr haben, wird die E-Mail mit einem temporären Fehler abgewiesen. Der einliefernde Mailserver wird daher versuchen die E-Mail ein paar Minuten später noch einmal zuzustellen. Damit sollte keine E-Mail verloren gehen. Als Admin behält man nach so einer Änderung einfach seinen Server im Auge und erhöht bzw. reduziert den Wert/die Grösse… Fertig.

Die RAM-Disk gibt AMaViS einen extremen Boost und steigert so dessen Performance enorm. Ich finde es kommt selten vor dass man so einfach ein so krasses Performance-Tuning hin bekommt. Nun laufen die E-Mails also schneller durch AMaViS und mein Postfix muss nicht mehr so lange auf die Filterung warten. WOOOOHOOOOO

Siehe auch: rspamd mit IMAPSieve

Fragen? Einfach melden.

DNS konfigurieren um die XMPP Information zu verteilen

Warum vergessen nur immer alle die DNS Informationen zu ihrem neuen Jabber-Server zu setzten? Ich bin heute sicher zum 12 mal nach einem Problem gefragt worden welches damit zusammen hing. Die Info fehlt aber auch in _fast_ jedem Howto. Kopieren denn wirklich alle nur noch Zeile für Zeile? Als Wikipedia mal einen Tag ausgesetzt hat, konnten tausende keine Hausaufgaben abgeben. Irgendwie habe ich dass Gefühl, wenn Google mal einen Tag aussetzten würde könnten tausende „Admins“ nichts installieren oder Probleme lösen ;-P

Also um es noch mal in Google zu werfen:

Damit die Kommunikation zwischen den Jabber-Server sauber läuft müssen die nötigen DNS Records vorhanden sein. Für meinen Bind schaut es so aus wie im folgenden Beispiel:

_jabber._tcp.jabber.kernel-error.de.       IN SRV   0 0 5269   jabber.kernel-error.de.
_xmpp-server._tcp.jabber.kernel-error.de.  IN SRV   0 0 5269   jabber.kernel-error.de.
_xmpp-client._tcp.jabber.kernel-error.de.  IN SRV   0 0 5222   jabber.kernel-error.de.

Testen lässt sich dieses am Ende natürlich mit dig:

$ dig SRV _xmpp-server._tcp.jabber.kernel-error.de +short
0 0 5269 jabber.kernel-error.de.

$ dig SRV _xmpp-client._tcp.jabber.kernel-error.de +short
0 0 5222 jabber.kernel-error.de.

Fragen? Einfach melden.

Ejabberd Dualstack IPv4 und IPv6

Wie so oft führen viele Wege nach Rom. Damit Ejabberd auf der IPv4 und den IPv6 Adressen gleichzeitig lauscht hat sich für mich folgender als gut erwiesen:

In der Konfigurationsdatei: /etc/ejabberd/ejabberd.cfg

Im Abschnitt Listening Ports einfach in die Portkonfiguration inet4 sowie inet6 aufnehmen:

{5222, ejabberd_c2s, [
                        inet4,
                        inet6,
                        {access, c2s},
                        {shaper, c2s_shaper},
                        {max_stanza_size, 65536},
                        %%zlib,
                        starttls, {certfile, "/etc/ejabberd/ejabberd.pem"}
                       ]},

Schon arbeitet Ejabberd mit beiden:

# netstat -an|grep 5222
tcp6       0      0 :::5222                 :::*                    LISTEN     
tcp6       0      0 *:5222                 *:*                    LISTEN    


Ach ja, Ejabberd Version ist gerade: 2.1.5

Fragen? Einfach melden.

Eigenen Jabber-Server betreiben: Warum und wie mit Openfire

Jabber, offiziell XMPP, ist ein offenes Messaging-Protokoll. Kein zentraler Betreiber, kein Vendor Lock-in, kein Unternehmen das die Nutzungsbedingungen diktiert. Jeder kann einen eigenen Server betreiben, und die Server sprechen untereinander. Wie E-Mail, nur für Messaging.

Warum ein eigener Server

Bei kommerziellen Messengern gibt man mit der Nutzung Rechte an seinen Inhalten ab. Die AGBs von AIM, ICQ, MSN und Co. erlaubten dem Betreiber die Verwertung aller Inhalte die über den Dienst liefen. Die Dienste gibt es größtenteils nicht mehr, aber das Muster ist geblieben. Ein eigener Server bedeutet: Eigene Regeln, eigene Daten, eigene Entscheidung welche Module aktiv sind.

Die Vorteile von XMPP: Open Source, Verschlüsselung per TLS, kein Single Point of Failure, und eine riesige Auswahl an Clients für jede Plattform.

Openfire

Nach Tests mit jabberd, ejabberd und Openfire bin ich bei Openfire hängengeblieben. Für einen kleinen Server mit Familie und Freunden bringt Openfire alles mit: Weboberfläche zur Administration, Plugin-System, IPv6-Support und einfache Installation unter Debian. Für einen großen öffentlichen Server würde ich anders entscheiden, aber für meinen Zweck passt es.

Die Installation unter Debian ist schnell erledigt. Die TLS-Konfiguration braucht etwas Handarbeit, dazu gibt es eigene Beiträge: Unsichere Cipher deaktivieren und S2S-Verbindungen mit fehlenden Intermediate-Zertifikaten.

Jabber auf dem DECT-Telefon

Um zu zeigen wie flexibel XMPP ist: Mein Siemens Gigaset C470IP hat ein Mobilteil C47H mit eingebautem Messenger. Das Telefon verbindet sich mit dem Jabber-Server und kann Nachrichten empfangen und verschicken. Ohne App, ohne Smartphone, direkt auf dem DECT-Telefon.

Gigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem MessangerGigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem Messanger neue NachrichtGigaset C470IP mit Mobilteil C47H online am Jabber Server mit seinem Messanger neue Nachricht
Der Jabber Messenger des Gigaset C47H ist online und mit dem Server verbunden.Am Gigaset C47H ist eine neue Jabber-Nachricht angekommen.Die Nachricht wird am Mobilteil gelesen. Antworten funktioniert genauso.

Fragen? Einfach melden.

Dovecot Quota einrichten: Postfachgröße begrenzen mit Warnungen und SQL

Ohne Quota wachsen IMAP-Postfächer bis die Platte voll ist. Dovecot bringt ein Quota-Plugin mit, das die Postfachgröße begrenzt und den Benutzer warnt bevor es eng wird. Bei vollem Postfach kann Dovecot eingehende Mails mit einem temporären Fehler abweisen, statt sie sofort zu bouncen. So hat der Benutzer Zeit aufzuräumen.

Plugin aktivieren

In conf.d/20-imap.conf und conf.d/20-lmtp.conf (oder 15-lda.conf) das Quota-Plugin laden:

# 20-imap.conf
protocol imap {
  mail_plugins = $mail_plugins quota imap_quota
}

# 20-lmtp.conf
protocol lmtp {
  mail_plugins = $mail_plugins quota
}

imap_quota sorgt dafür dass Mailclients die Quota-Information per IMAP abfragen können (GETQUOTA/GETQUOTAROOT). Die meisten Clients zeigen dann einen Fortschrittsbalken.

Quota-Backend und Standardgröße

In conf.d/90-quota.conf:

plugin {
  quota = count:User quota
  quota_vsizes = yes
  quota_rule = *:storage=512M
}

count ist das empfohlene Backend ab Dovecot 2.2+. Es speichert die Quotadaten in der Index-Datei und muss nicht jedes Mal alle Mails auf der Platte zählen. Das alte dirsize-Backend funktioniert zwar noch, wird aber bei großen Postfächern langsam. quota_rule = *:storage=512M setzt die Standardgröße für alle Postfächer auf 512 MB.

Quota Warnings

Dovecot kann bei bestimmten Schwellenwerten ein Script aufrufen, das eine Warnung verschickt:

plugin {
  quota_warning = storage=80%% quota-warning 80 %u
  quota_warning2 = storage=95%% quota-warning 95 %u
}

service quota-warning {
  executable = script /usr/local/bin/quota-warning.sh
  user = vmail
  unix_listener quota-warning {
    user = vmail
  }
}

Die doppelten Prozentzeichen (%%) sind nötig weil Dovecot % als Variablen-Prefix interpretiert. Das Script /usr/local/bin/quota-warning.sh bekommt den Schwellenwert und die E-Mail-Adresse als Parameter:

#!/bin/sh
PERCENT=$1
USER=$2
echo "Ihr Postfach $USER ist zu $PERCENT% belegt.
Bitte loeschen oder archivieren Sie aeltere E-Mails." | \
  mail -s "Postfach $USER: $PERCENT% belegt" "$USER"

Individuelle Quotas per SQL

Wenn nicht jeder Benutzer die gleiche Postfachgröße bekommen soll, lässt sich die Quota per SQL-Abfrage pro Benutzer setzen. In der dovecot-sql.conf.ext:

user_query = SELECT \
  home, uid, gid, \
  CONCAT('*:storage=', quota_mb, 'M') AS quota_rule \
  FROM virtual_users \
  WHERE email = '%u'

Die Tabelle virtual_users braucht dafür ein Feld quota_mb. Dovecot übernimmt den Wert aus dem SQL-Ergebnis und überschreibt damit die Standardregel aus der Config. Benutzer ohne Eintrag bekommen weiterhin die 512 MB aus quota_rule.

Verhalten bei vollem Postfach

Standardmäßig gibt Dovecot bei vollem Postfach einen permanenten Fehler zurück und Postfix bounced die Mail. Mit der folgenden Einstellung wird stattdessen ein temporärer Fehler gesendet (4xx), damit Postfix die Mail in der Queue behält und es später nochmal versucht:

plugin {
  quota_exceeded_message = Quota exceeded, please try again later.
}

# In der LDA/LMTP Config:
quota_full_tempfail = yes

So hat der Empfänger Zeit sein Postfach aufzuräumen, ohne dass Mails verloren gehen. Fragen? Einfach melden.

Greylisting mit Postfix und Postgrey einrichten

Greylisting ist ein einfacher Trick gegen Spam: Beim ersten Zustellversuch lehnt der Mailserver die Mail mit einem temporären Fehler ab (4xx). Ein regulärer Mailserver versucht es nach ein paar Minuten erneut und die Mail wird zugestellt. Spam-Botnets dagegen arbeiten nach dem „fire and forget“ Prinzip. Die probieren es kein zweites Mal, weil sie in der Zeit lieber den nächsten Empfänger anschreiben. Damit lassen sich 80 bis 90 Prozent der Botnet-Zustellungen abfangen, ohne eine einzige Mail filtern zu müssen.

Wie es funktioniert

Postgrey speichert bei jedem Zustellversuch ein Triplet aus Absender-Adresse, Empfänger-Adresse und Client-IP. Beim ersten Versuch wird die Mail abgelehnt. Kommt derselbe Server nach Ablauf der Wartezeit (Standard: 5 Minuten) nochmal, wird die Mail durchgelassen. Bekannte Triplets werden 35 Tage gespeichert, danach lernt Postgrey den sendenden Server automatisch und lässt ihn ohne Verzögerung durch (Auto-Whitelist).

Installation

# Debian/Ubuntu
apt-get install postgrey

# FreeBSD
pkg install postgrey

Nach der Installation lauscht Postgrey auf 127.0.0.1:10023 (Debian) bzw. 127.0.0.1:10030 (FreeBSD, je nach Config). Prüfen mit ss -tlnp | grep postgrey oder sockstat -4l | grep postgrey.

Postfix-Integration

In der main.cf den Postgrey-Check in die smtpd_recipient_restrictions einfügen, nach den Authentifizierungs-Checks und vor den RBL-Checks:

smtpd_recipient_restrictions =
    permit_mynetworks,
    permit_sasl_authenticated,
    reject_unauth_destination,
    check_policy_service inet:127.0.0.1:10023,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client bl.spamcop.net

Nach einem postfix reload ist Greylisting aktiv.

Im Log

Beim ersten Versuch wird die Mail abgelehnt:

postgrey: action=greylist, reason=new, client_name=mail.example.de, sender=user@example.de
postfix/smtpd: NOQUEUE: reject: 450 4.2.0 Recipient address rejected: Greylisted

Beim zweiten Versuch (nach Ablauf der Wartezeit) wird durchgelassen:

postgrey: action=pass, reason=triplet found, delay=355, client_name=mail.example.de

Bekannte Server werden automatisch durchgelassen:

postgrey: action=pass, reason=client AWL, client_name=mail.example.de

Limitationen

Greylisting verzögert die erste Mail von jedem neuen Absender um einige Minuten. Für zeitkritische Mails (Passwort-Resets, Zwei-Faktor-Codes) kann das ein Problem sein. Postgrey führt deshalb eine Whitelist mit bekannten großen Providern (/etc/postgrey/whitelist_clients), die nie verzögert werden.

Inzwischen setzt auch rspamd Greylisting um, als Teil seines Score-basierten Ansatzes. Dort wird nur gegrey­listet wenn der Spam-Score in einem Graubereich liegt. Mails die eindeutig Spam oder eindeutig sauber sind, werden sofort abgelehnt oder zugestellt. Fragen? Einfach melden.

Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑