Let’s Encrypt Zertifikate für Postfix und Dovecot einrichten

In letzter Zeit wird die Verwendung der kostenlosen Zertifikate von Let’s Encrypt immer beliebter. Deshalb ist es naheliegend, diese auch für Verschlüsselung der Mails bei Postfix zu verwenden. Im folgenden sind die wenigen Schritte für die Einrichtung erklärt, die bei einem Ubuntu 18.04 notwendig sind.

Installation

Let’s Encrypt können mit dem certbot erzeugt werden. Die Installation des Programms bei Ubuntu 18.04 erfolgt mit den folgendenBefehlen.

sudo apt update
sudo apt install python-certbot-apache

Erzeugung eines Zertifikates

Das Zertifikat wir mit dem Programm certbot erzeugt. Da die Verifizierung des Host über den Webauftritt erfolgt. Ist es zwingend erforderlich, dass ein Apache auf dem Server installiert ist. Das Programm certbot macht dann die notwendigen Anpassungen an der Konfiguration des Apache Webservers. Mit der Option -d werden die Hostnamen angegeben, für welche das Zertifikat ausgestellt werden soll. Dabei ist es möglich das Zertifikat gleich für mehrere Hostnamen auszustellen. Nach dem ausführen des Programms certbot werden zudem einige Fragen gestellt, deren Beantwortung für das anpassen der Konfiguration des Apache Webservers notwendigen sind. Mit dem folgenden Befehl testet man z.B. das Ausstellen eines Zertifikates für die Hostnamen www.purrucker.de, purrucker.de imap.purrucker.de und smtp.purrucker.de. 

sudo certbot --apache --staging -d www.purrucker.de -d purrucker.de -d imap.purrucker.de -d smtp.purrucker.de

Wenn alles funktioniert, kann man das Kommando ohne die Option „–staging“ ausführen. Dann fordert certbot beim Let’s-Encrypt-Projekt die generierten Zertifikate an, lädt diese herunter, installiert alle erforderlichen Dateien in das Verzeichnis /etc/letsencrypt, verändert die Apache-Konfiguration und startet Apache schließlich neu.

Einbindung des Zertifikates

Die Einbindung des Zertifikates in den Apache Webserver hat das Programm certbot erledigt. Bei Postfix und Dovecot muss die Einbindung jedoch von Hand erfolgen. Bei Postfix fügt man dazu die beiden folgenden Zeilen in die Datei /etc/postfix/main.cf ein.

smtpd_tls_cert_file= /etc/letsencrypt/live/www.purrucker.de/fullchain.pem
smtpd_tls_key_file= /etc/letsencrypt/live/www.purrucker.de/privkey.pem

Bei Dovecot benötigt man die drei folgenden Zeilen in der Datei /etc/dovecot/conf.d/10-ssl.conf.

ssl = yes
ssl_cert = </etc/letsencrypt/live/www.purrucker.de/fullchain.pem
ssl_key  = </etc/letsencrypt/live/www.purrucker.de/privkey.pem

Danach müssen beide Programme einmal neu gestartet werden.

service postfix restart
service dovecot restart

Automatische Erneuerung des Zertifikates

Das Let’s Encrypt Zertifikat ist grundsätzlich immer nur drei Monate gültig. Deshalb ist es notwendig, dieses regelmäßig zu erneuern. Um dies nicht immer von Hand machen zu müssen, sollte man sich dazu einen wöchentlichen Cronjob anlegen. Dazu einfach die Datei /etc/cron.weekly/letsencrypt mit folgendem Inhalt anlegen und ausführbar machen.

#!/bin/sh
# Datei /etc/cron.weekly/letsencrypt
certbot renew
result=$(find /etc/letsencrypt/live/ -type l -mtime -1 )
if [ -n "$result" ]; then
  systemctl restart postfix
  systemctl restart dovecot
fi

SPAM-E-Mails aus der Postfix-Queue löschen

Heute wurden mit einem geklauten Benutzerzugang über einen unserer Server innerhalb weniger Minuten ca. 10.000 SPAM-E-Mails verschickt. Ich habe den betroffenen Zugang natürlich sofort gesperrt, nachdem durch die Hohe Anzahl von E-Mails der Alarm ausgelöst wurde. Aber was macht man jetzt mit den ganzen E-Mails in der Queue von Postfix?

Durch eine Analyse der E-Mail-Adressen der Empfänger in der Ausgabe des Befehls mailq zeigte sich, dass die E-Mail-Adressen eine bestimmte Systematik hatten. Die meisten enthielten das word admin. Durch die Kombination von ein paar Unix-Befehlen konnte ich deshalb die meisten SPAM-E-Mails löschen, bevor sie versendet wurden. Hier der Befehl, welchen ich dazu verwendet habe:

mailq | awk 'BEGIN { RS = "" } / admin@.*$/ { print $1 }' | tr -d '*!' | postsuper -d -

Mehrere E-Mail-Adressen für einen Account bei Apple Mail benutzen

Ich musste heute etwas suchen, um herauszufinden, wie man bei Apple Mail mehrere E-Mail-Adressen für einen Account einstellen kann. Das ist nämlich so einfach, dass man nicht gleich drauf kommt. Und laut Google haben lustiger Weise viele das Problem.

Die Lösung ist: Man trägt einfach alle E-Mail-Adressen kommasepariert bei den Account-Informationen im Feld E-Mail-Adresse ein. Anschliessend kann man diese E-Mail-Adressen beim Verfassen über das Drop-Down Accounts auswählen, bzw. Mail wählt selbständig beim Antworten die korrekte Alias-Adresse aus.

Anzeigen der Postfachgröße bei Exchange 2010

Wer einen Server mit Microsoft Exchange betreibt ist oft auf der Suche nach den Benutzern, die zu viel Speicherplatz belegen. Leider gibt es in der grafischen Konsole von Exchange 2010 keine Möglichkeit in einer Liste alle Mailboxen mit ihrer Größe anzuzeigen. Um eine solche List zu erhalten benötigt man also die Power Shell. Die brauchbaren Kommandos für die Power Shell haben jedoch leider den Nachteil, dass Sie sich durch ihre Länge und komplexität nicht sonderlich gut merken lassen. Deshalb habe ich mir im folgenden mal drei nützliche Varianten zum ermitteln der Mailboxgröße aufgeschrieben.

Alle Mailboxen nach Größe anzeigen

get-mailboxdatabase | get-mailboxstatistics | Sort -Property TotalItemSize -descending| select-object DisplayName,@{expression={$_.TotalItemSize.value.ToMB()}}, Itemcount,ServerName

Alle Mailboxen nach Größe und mit Datenbank anzeigen

get-mailboxdatabase | get-mailboxstatistics | Sort -Property TotalItemSize -descending| select-object DisplayName,@{expression={$_.TotalItemSize.value.ToMB()}}, Itemcount,ServerName,Database |ft

Alle Mailboxen einer Datenbank auflisten
(anstelle von Test muss hier der DB-Name eingesetzt werden)

get-Mailboxdatabase -Identity "Test" | get-mailboxstatistics | Sort -Property TotalItemSize -descending| select-object DisplayName,@{expression={$_.TotalItemSize.value.ToMB()}},Itemcount,ServerName

Autodiscover bei Outlook abschalten

Die Autodiscover Funktion von Outlook ist eine nützliche Sache, die einen bei gemischten Umgebungen mit mehre Firewalls, DNS- und Exchangeservern in die Verzweiflung treiben kann. Vielleicht hat Microsoft deshalb ja sogar einen Song über Autodicover auf der Technet-Webseite veröffentlicht 😉


http://gallery.technet.microsoft.com/The-Autodiscover-Song-a68b9f7c

Leider läuft ab Outlook 2007 ohne autodiscover einiges nicht mehr (z.B. Free and Busy Informationen, der Abwesenheitsassist, das Offline Address Book usw). Dies lässt sich allerdings umgehen, indem man für den Client das Autodiscover abzuschalten. Im folgenden ein paar Registry-Einträge einem dies ermöglichen:

HKCU\Software\Microsoft\Office\12.0\Outlook\AutoDiscover
DWORD: DisableAutoStartup
Set to 1
HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\12.0\Outlook\AutoDiscover
DWORD: ZeroConfigExchange
Set to 1
2. Free Busy:
Outlook 2007 zwingen den Public Folder Free/Busy zu nutzen:
Key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Options\Calendar
DWORD: UseLegacyFB
Wert:
0 (oder nicht vorhanden) = default Einstellung - Autodiscover nutzen
1 = public folder free/busy nutzen

Berechtigungen bei einem Exchange Server 2010 neu setzen

Unter bestimmten Umständen kann es dazu kommen, dass die Berechtigungen bei einem Exchange Server 2010 Server falsch gesetzt sind. Ich hatte neulich z.B. den Fall, dass interne E-Mails trotzt korrekter Konfiguration nicht von einem zum anderen Server übermittelt wurden.

Für solche Fälle gibt es den Schalter /preparelegacyexchangepermissions für die setup.exe. Wenn man die setup.exe mit diesem Parameter auf dem Server erneut startet, werden die Berechtigungen erneut gesetzt.

Outlook 2003 für Exchange 2010 verwenden

Wenn man mit Microsoft Office Outlook 2003 auf ein Microsoft Exchange Server 2010-Postfach zugreift, werden E-Mail die gelöscht oder verschoben wurden noch längere Zeit im Ordner angezeigt. Dies liegt daran, dass Microsoft bei Exchange 2010 keine UDP-Benachrichtigungen mehr an Outlook versendet.

Da sehr viele Kunden noch Outlook 2003 einsetzen, hat Microsoft diese Funktion aber mit „Update Rollup 3 für Exchange Server 2010 Service Pack 1“ wieder ermöglicht. Damit die UDP-Benachrichtigungen wieder gesendet werden, muss allerdings zusätzlich der folgende Registrierungsschlüssel inklusive Subschlüssel erstellt werden:

SubkEy-Speicherort: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC\ParametersSystem
SubkEy-Name: EnablePushNotifications
Typ: REG_DWORD
Wert: 1

Nähere Informationen findet man in dem Microsoft Knowledge Base Artikel 2009942.

Mit Postfix einen BCC automatisch setzen

Ab Postfix 2.1 kann man mit der Direktive recipient_bcc_maps einen BCC (blind carbon-copy) Empfänger automatisch setzen lassen.

Wenn man bei E-Mails von user1@domain1.com automatisch user2@domain2.com als BCC Empfänger setzen möchte, legt man eine Datei /etc/postfix/recipient_bcc an, die wir folgt aussehen sollte:

user1@domain1.com user2@domain2.com

Danach erzeugt man eine Hash-Tabelle aus der Datei:

postmap /etc/postfix/recipient_bcc

Zum Schluss bindet man die Datei in Postfix ein, indem man in die Datei main.cf zusätzlich die folgende Zeile schreibt und Postfix einmal neu startet:

recipient_bcc_maps = hash:/etc/postfix/recipient_bcc

Verbesserung des SPAM-Schutzes bei ISPConfig 3 / Postfix

Wenn man einen Linux-Server mit ISP-Config 3 nach Anleitung installiert, ist der SPAM-Schutz des Postfix meist noch verbesserungswürdig. Meine Meinung nach sollte man auf jeden Fall strengere Kriterien für E-Mail-Absender einbauen. Es sollten z.B. keine E-Mails von unvollständigen Domains angenommen werden und eine SBL (SPAM Block List) wie Spamhaus eingebunden werden. Dazu muss man in der Datei /etc/postfix/main.cf die Zeile

smtpd_sender_restrictions = check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf

wie folgt erweitertern.

smtpd_sender_restrictions = reject_rbl_client sbl-xbl.spamhaus.org, reject_rbl_client cbl.abuseat.org, reject_non_fqdn_sender, reject_unknown_sender_domain, check_sender_access mysql:/etc/postfix/mysql-virtual_sender.cf

Eigene SSL-Zertifikate bei Exchange 2007 und 2010

Oft werden für Exchange Server eigene SSL-Zertifikate von thawte/VeriSign, Comodo oder ähnlichen Ausstellern verwendet. Dadurch gibt es bei dem ersten Aufruf von einem Client aus keine lästigen Meldungen, bei denen das „Zertifikat eines unbekannten Ausstellers“ als vertrauenswürdig bestätigt werden muss. Wenn der Exchange-Server im LAN eine anderen Namen oder eine andere Domäne verwendet meldet Outlook nach dem Wechsel des Zertifikates bei jedem Start: „Der Name auf dem Sicherheitszertifikat ist ungültig oder stimmt nicht mit dem Namen der Webseite überein.“ Dies liegt daran, dass der Common Name des Zertifikates nicht dem internen Namen des Exchange-Servers entspricht.

Um das Problem zu lösen muss man in der Exchange Management Shell die folgenden Befehle eingeben (dabei sollten der CAS_Server_Name und die URL natürlich entsprechend angepasst werden):

Set-ClientAccessServer -Identity CAS_Server_Name -AutodiscoverServiceInternalUri https://mail.contoso.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity "CAS_Server_Name\EWS (Default Web Site)" -InternalUrl https://mail.contoso.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity "CAS_Server_name\oab (Default Web Site)" -InternalUrl https://mail.contoso.com/oab
Set-UMVirtualDirectory -Identity "CAS_Server_Name\unifiedmessaging (Default Web Site)" -InternalUrl https://mail.contoso.com/unifiedmessaging/service.asmx

Wobei der letzte Befehlt nur bei Exchange 2007 benötigt wird. Danach sollte man im IIS Manager noch die MSExchangeAutodiscoverAppPool Anwendung im Anwendungspool „Wiederverwenden“ (tolle Übersetzung Microsoft!)

Nähere Informationen sind bei Microsoft im Knowledge Base Artikel 940726 zu finden.