Aktuell bearbeite ich die Ablösung eines Mailservers. Die bisherige E-Mail Infrastruktur besteht aus einem Mailserver der die Postfächer beheimatet und Dienste wie SMTP oder IMAP zur Verfügung stellt und einem Frontend-Server der als Haupt Mailexchanger (MX) die nicht Authentifizierten E-Mails annimmt. Temporär wird ein neuer Mailserver hinzugefügt, alle Konten müssen sychronisiert werden und für eine Übergangszeit vermittelt der MX-Server Mails an zwei Server die die Postfächer bereitstellen.

Der Text auf dieser Seite ist z.T. noch in Arbeit, da einige Informationen jetzt schon interessant sein könnten stelle ich die Seite bereits online.

Bert Zulauf

Vorarbeiten und Rahmenbedingungen

Zu den Rahmenbedingungen gehört die Nutzung einer Webmail-Lösung, aktuell auf Basis von Roundcube und die Verwaltung von Kunden und Postfächern mit Froxlor. Die aktuellen Postfächer werden durch einen Courier IMAP-Server bereitgestellt, sollen aber zukünftig durch Dovecot ausgeliefert werden. Als Mail Transfer Agent (MTA) soll weiterhin Postfix eingesetzt werden. Die aktuelle Lösung zur Spamerkennung und Markierung auf Basis von Spamassasin soll überdacht werden.

Außerdem sollen nicht mehr benötigte Adressen identifiziert und gelöscht werden und die Passwort-Sicherheit erhöht werden.

Hilfreiche Links

Bei der Vorbereitung und Bearbeitung waren folgende Seiten hilfreich, hatten gute Hinweise oder für mich passende Anleitungen:

• Mailserver mit Dovecot, Postfix, MySQL und Rspamd unter Debian 9 Stretch (von Thomas Leister)
• Mailserver mit Dovecot, Postfix, MySQL und Rspamd unter Debian 10 Buster (von Thomas Leister)

Identifizieren von nicht mehr benötigten E-Mailadressen

Zum Auffinden von potentiell nicht mehr benötigten Adressen habe ich überlegt zuerst zu zu analysieren welche Postfächer seit längerer Zeit nicht mehr abgerufen wurden. Bei geeigneten Logfiles, die einen passenden Zeitraum abdecken, kann man in den Ordner wechseln in dem die betroffenen Postfächer liegen (für eine Liste oder Übersicht der Postfächer) und prüfen lassen ob zu den Postfächern Zugriffe über das IMAP-Protokoll vorkamen. Voraussetzung wäre hier, dass wiedererkennbare Teile des Domain-Namens im Namen des Postfachordners vorkommen:

for i in $( ls |grep domain ); do zgrep $i /var/log/mail.lo*|grep imapd || echo "kein Treffer:"$i; done |grep Treffer

Alternativ ist auch eine Analyse der Alters-Struktur des Posteingangs interessant: Sind in den letzten Jahren E-Mails eingegangen die kein Spam waren. Oder liegen beispielsweise auch sehr viele und/oder alte E-Mails innerhalb der Ordner-Struktur “new”.

for i in $(rgrep domain /var/customers/mail/Mailbox/new/* | grep customers | cut -d: -f1); do cat $i |grep From | cut -d: -f2; done | less

Gib es also überhaupt E-Mails beispielsweise aus der selben Domain von Kolleginnen oder Kollegen könnte ein Kriterium sein.

Mail Exchanger als Weiche

Um mehrere Domains umzuziehen und den Umzugszeitplan an den Nutzenden und Kunden zu orientieren spielen zwei Zeitpunkte eine Rolle:

1. Der Zeitpunkt an dem das Postfach mit allen Mails auf dem neuen Server verfügbar ist
2. Der Zeitpunkt an dem neue eingehende Mails an den neuen Postfach-Server ausgeliefert werden

Den ersten Zeitpunkt stimmt man mit den Kunden oder Nutzer*innen ab und um mit dem 2. Zeitpunkt flexibel zu halten kann man eine Weiche auf dem vorgeschalteten Mail Exchanger einrichten. Um E-Mailkonten mit dieser Weiche je nach Umstellungszeitpunkt pro Domain umzuziehen wird neben der vorhandenen Konfiguration zur Weiterleitung der E-Mails an den Postfach-Server eine Empfänger basierte Transportroute definiert (transport_maps). In der Transportroute kann dann zwischen dem Hauptweg der E-Mailzustellung und Nebenwegen, wie beispielsweise dem neuen Postfach-Server unterschieden werden. Nach der Umstellung kann man den neuen Postfachserver als Hautroute eintragen und die Nebenrouten wieder entfernen.

In der Hauptkonfiguration des Postfix-Mailservers wird auf dem Mail Exchanger über transport_maps die Konfiguration für diese Routen angegeben:

relayhost = [mail.alterhauptserver.de]
relay_recipient_maps = hash:/etc/postfix/relay_recipients
transport_maps = hash:/etc/postfix/transport

In der referenzierten Konfiguration /etc/postfix/transport werden die Nebenrouten erstellt:

### Alles an
*   smtp:[mail.alterhauptserver.de]

### Weiche
###
### mail.neuerserver.de 
# mails an 
Domainbeispiel1.de  smtp:[mail.neuerserver.de]
Domainbeispiel2.de  smtp:[mail.neuerserver.de]
Domainbeispiel3.de  smtp:[mail.neuerserver.de]

Um auf dem Mail Exchanger sofort E-Mail, die keinen relevanten Empfänger adressieren abweisen zu können muss der Mail Exchanger Informationen über die relevanten Empfänger erhalten. Die Information liegt über das Managementsystem des Postfachservers (Froxlor) vor und wird manuell bei neuen Postfächern ausgelöst. Aus der Userdatenbank auf dem Postfachserver werden alle Postfachnutzer zusammengestellt und mit dem Skript get-relay-recipients auf den Mail Exchanger übertragen und dann als /etc/postfix/relay_recipients abgelegt und mittels postmap /etc/postfix/relay_recipients als Konfiguration aktiviert.

#!/bin/bash

MAIL_HOST=mx.zlauf.de
RELAY_RECIPIENTS=/etc/postfix/relay_recipients
TMP_FILE=/etc/postfix/relay_recipients-mail.zlauf.de
LOCAL_FILE=/tmp/relay_recipients

# get relay_recipients from froxlor-db

/usr/bin/mysql -uDB-User -pGeheim froxlor -s -r -N -h 0 -e "SET @allow =\"x\";SELECT email , @allow AS allow FROM mail_virtual ORDER BY email ASC LIMIT 1000;" > $LOCAL_FILE

scp  $LOCAL_FILE root@$MAIL_HOST:$TMP_FILE

ssh  root@mx.zlauf.de  "cat /etc/postfix/relay_recipients-* > /etc/postfix/relay_recipients; postmap /etc/postfix/relay_recipients; service postfix restart;"

Greylisting

Auf dem Mail Exchanger werden E-Mails mit der Methode Greylisting angenommen, nach dem der Absender durch eine positive Mailzustellung bereits bekannt ist. Bei der Erstzustellung werden E-Mails verzögert und es wird ein erneuter Zustellversuch abgewartet/provoziert: Nur E-Mails die von Mailservern mit einem Standard konformen Verhalten (mehrere Zustellversuche nach kurzer Zeit) ein zweites mal zugestellt werden, werden so bei der Methode Greylisting berücksichtigt und der Absender-Mailserver wird zur Mailannahme zertifiziert.

Letsencrypt für die Zertifikate

Die Mailzertifikate für den Mail Exchanger mx.zlauf.de und für den Postfachserver mail1.zlauf.de werden über den Dienst Let’sencrypt bereitgestellt und regelmäßig automatisiert aktualisiert.

Sieve

Der neue Postfachserver stelle Sievefunktionalitäten zur Filterung von E-Mails oder zur Erstellung von Abwesenheitsnachrichten auf dem Mailserver bereit.

Allgemeine Informationen zu dem neuen Mailserver

Die folgenden Informationen beziehen sich im wesentlichen auf die E-Mail-Postfächer. E-Mail-Weiterleitungen werden ebenso umgezogen es sind bei Weiterleitungen jedoch keine Änderungen für die Nutzer*innen nötig oder möglich.

Der neuen Servername sowohl für den Zugriff auf das Postfach (IMAP) wie auch für den Versand von E-Mails aus dem Postfach (SMTP) ist: mail1.zlauf.de
Als Benutzername gilt weiterhin die E-Mail-Adresse. Sowohl für den Zugriff auf die E-Mails im Postfach, wie auch für das Versenden von E-Mails über das Postfach muss jeweils eine Kombination von Benutzernamen und Passwort im E-Mail-Client/Programm angegeben werden. Bei der Umstellung werden alle Mails auf den neuen Server synchronisiert ggf. gibt es eine Umstellung des Ordners für Spam-E-Mails.

Zugangsdaten des neuen Servers

IMAP-Server: mail1.zlauf.de
Port: 143
Verbindungssicherheit: STARTSSL
Authentifizierungsmethode: Passwort, normal

SMTP-Server: mail1.zlauf.de
Port: 25
Verbindungssicherheit: STARTSSL
Authentifizierungsmethode: Passwort, normal

Spam-E-Mail-Behandlung

Auf dem neuen Server heißt der Ordner “Junk” und E-Mails die zukünftig in diesen Ordner verschoben werden, werden danach vom Mailserver direkt als Spam-E-Mails klassifiziert und besser erkannt (der Server lernt diese E-Mails als Spam-E-Mails an). Wenn fälschlich E-Mails als Spam klassifiziert wurden und diese im “Junk” Ordner einsortiert wurden, können diese E-Mails in einen anderen Ordner verschoben werden (beispielsweise in den Posteingang) und auch in diesem Fall lernt der Server, dass derartige E-Mails zukünftig nicht als Spam zu klassifizieren sind und die Spam-Erkennungsrate kann verbessert werden.

Urlaubsbenachrichtigungen

Der neue Mailserver bietet die Möglichkeit E-Mails auf dem Server direkt zu filtern und damit auch die Möglichkeit eine Abwesenheitsbenachrichtigung einzustellen. Die Filtermöglichkeiten werden über eine sogenannte “Sieve-Schnittstelle” möglich. Um diese Schnittstelle zu nutzen gibt es mehrere Wege; auf diese beiden Möglichkeiten wird später noch eingegangen:

• Abwesenheitsbenachrichtigungen über ein Plugin mit dem E-Mail Client Mozilla Thunderbird
• Abwesenheitsbenachrichtigungen über den Webmail-Client Roundcube

Konfiguration von Mozilla Thunderbird

Die Konfigurationsdaten oben und die entsprechenden Benutzerdaten werden wie folgt für Mozilla Thunderbird angegeben für den Zugriff über IMAP auf das Postfach:

Und für das Versenden von E-Mails (SMTP) über das Postfach:

Abwesenheitsbenachrichtigungen mit Mozilla Thunderbird

Versierte Nutzer des E-Mail Client Thunderbird können die folgende Erweiterung herunterladen https://addons.thunderbird.net/de/thunderbird/addon/sieve/ und ein eigenes kleines Filterprogramm erstellen (Beispiele gibt es hier: https://mail.ruhr-uni-bochum.de/mail/faq/sieve). Ich werde den Code für einen einfachen Filter später für die Nutzung zur Verfügung stellen

Einstellungen für Spam-Mails mit Mozilla Thunderbird

Webmail-Schnittstelle

Um über die Webmailschnittstelle auf den neuen Server zuzugreifen verwenden Sie Ihre E-Mailadresse als Benutzername und das neue Passwort. Wählen Sie den Server mail1.zlauf.de aus.

Abwesenheitsbenachrichtigungen mit Roundcube Webmail

Eine Abwesenheitsbenachrichtigung kann man über die Webmail-Schnittstelle (https://webmail.zulauf-online.de) einrichten über den Menüpunkt Einstellungen, Abwesenheit.