Um das tägliche Upate der spamassassin-Datenbank durchzuführen, muss das erst unter Debian aktiviert werden. Die Aktivierung erfolgt in der Datei /etc/default/spamassassin:

# /etc/default/spamassassin
# Duncan Findlay

# WARNING: please read README.spamd before using.
# There may be security risks.

# If you're using systemd (default for jessie), the ENABLED setting is
# not used. Instead, enable spamd by issuing:
# systemctl enable spamassassin.service
# Change to "1" to enable spamd on systems using sysvinit:
ENABLED=1

# Options
# See man spamd for possible options. The -d option is automatically added.

# SpamAssassin uses a preforking model, so be careful! You need to
# make sure --max-children is not set to anything higher than 5,
# unless you know what you're doing.

OPTIONS="--create-prefs --max-children 5 --helper-home-dir"

# Pid file
# Where should spamd write its PID to file? If you use the -u or
# --username option above, this needs to be writable by that user.
# Otherwise, the init script will not be able to shut spamd down.
PIDFILE="/var/run/spamd.pid"

# Set nice level of spamd
#NICE="--nicelevel 15"

# Cronjob
# Set to anything but 0 to enable the cron job to automatically update
# spamassassin's rules on a nightly basis
CRON=1

Wenn der Cronjob mit der Fehlermeldung

error: unable to refresh mirrors file for channel updates.spamassassin.org, using old file
channel: could not find working mirror, channel failed
sa-update failed for unknown reasons

abbricht, dann liegt das an falschen Zugriffsberechtigungen im Verzeichnis /var/lib/spamassassin. Die Korrektur erfolgt mit:

# chown -R debian-spamd:debian-spamd /var/lib/spamassassin/

Normalerweise verwendet der Courier-Server für seine SSL-verschlüsselten Verbindungen (pop3-ssl und imap-ssl) selbstsignierte Zertifikate. Will man eigene offizielle Zertifikate verwenden, so müssen das Zertifikat und der private Schlüssel in einer Datei vorliegen.
Privater Schlüssel: /etc/ssl/example.com.key
Zertifikat: /etc/ssl/example.com.crt

cat /etc/ssl/example.com.key /etc/ssl/example.com.crt >> /etc/courier/imapd.pem

Ein zweiter Schritt ist ein starker DH-Schlüssel. Ich habe einen mit 4096 bits erstellt:

openssl dhparam -out /etc/courier/dhparams.pem 4096

Hintergrund für den starken Schlüssel: defaultmäßig wird ein DH-Schlüssel mit 768 bit ausgestellt. Dieser wird für z.B. von Thunderbird als (zu Recht) zu schwach empfunden und die Verbindung zum Courier-Server nicht aufgebaut.

Installation von bind9

Zuerst einmal bind9 installieren:

apt-get install bind9
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
  bind9utils
Vorgeschlagene Pakete:
  bind9-doc resolvconf ufw
Die folgenden NEUEN Pakete werden installiert:
  bind9 bind9utils
0 aktualisiert, 2 neu installiert, 0 zu entfernen und 3 nicht aktualisiert.
Es müssen 482 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 1.654 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] J
Holen: 1 http://security.debian.org/ jessie/updates/main bind9utils amd64 1:9.9.5.dfsg-9+deb8u3 [168 kB]
Holen: 2 http://security.debian.org/ jessie/updates/main bind9 amd64 1:9.9.5.dfsg-9+deb8u3 [314 kB]
Es wurden 482 kB in 0 s geholt (1.571 kB/s).
Vorkonfiguration der Pakete ...
Vormals nicht ausgewähltes Paket bind9utils wird gewählt.
(Lese Datenbank ... 49778 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../bind9utils_1%3a9.9.5.dfsg-9+deb8u3_amd64.deb ...
Entpacken von bind9utils (1:9.9.5.dfsg-9+deb8u3) ...
Vormals nicht ausgewähltes Paket bind9 wird gewählt.
Vorbereitung zum Entpacken von .../bind9_1%3a9.9.5.dfsg-9+deb8u3_amd64.deb ...
Entpacken von bind9 (1:9.9.5.dfsg-9+deb8u3) ...
Trigger für man-db (2.7.0.2-5) werden verarbeitet ...
Trigger für systemd (215-17+deb8u2) werden verarbeitet ...
bind9utils (1:9.9.5.dfsg-9+deb8u3) wird eingerichtet ...
bind9 (1:9.9.5.dfsg-9+deb8u3) wird eingerichtet ...
Lege Gruppe »bind« (GID 124) an ...
Fertig.
Lege Systembenutzer »bind« (UID 120) an ...
Lege neuen Benutzer »bind« (UID 120) mit Gruppe »bind« an ...
Erstelle Home-Verzeichnis »/var/cache/bind« nicht.
wrote key file "/etc/bind/rndc.key"
#
Trigger für systemd (215-17+deb8u2) werden verarbeitet ...

Da der bind9-daemon nach der Installation sofort gestartet wird, wird er sofort gestoppt:

systemctl stop bind9.service

In der systemd-Konfigurationsdatei für den bind9 muss der Containerpfad für den chroot angegeben werden (Option -t).

vim /etc/systemd/system/multi-user.target.wants/bind9.service
[Unit]
Description=BIND Domain Name Server
Documentation=man:named(8)
After=network.target

[Service]
ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot
ExecReload=/usr/sbin/rndc reload
ExecStop=/usr/sbin/rndc stop

[Install]
WantedBy=multi-user.target

Um im systemd dem bind9 mitzuteilen, dass er in einem chroot arbeiten soll, muss folgendes Verzeichnis und Konfigurationsdatei angelegt werden:

mkdir /etc/systemd/system/bind9.service.d
vim /etc/systemd/system/bind9.service.d/chroot.conf
[Service]
ExecStart=
ExecStart=/usr/sbin/named -f -u bind -t /var/bind9/chroot

Die Angabe der Änderung in der Datei /etc/systemd/system/bind9.service.d/chroot.conf hat den Vorteil, dass die Konfigurationsdatei des Maintainers /etc/systemd/system/multi-user.target.wants/bind9.service weiterhin eingelesen wird (es könnten ja Änderungen und Verbesserungen auch dort erfolgen!), diese aber punktuell angepasst werden kann. Alternativ könnte man die Datei /etc/systemd/system/multi-user.target.wants/bind9.service auch nach /etc/systemd/system kopieren und dort anpassen. Dann wird /etc/systemd/system/multi-user.target.wants/bind9.service nicht mehr eingelesen, d.h. dass dort vom Maintainer durchgeführte Änderungen bzw. Verbesserungen später keine Relevanz mehr haben werden. Weitere Details dazu in der Manpage von systemd.unit(5)

Die Änderung muss dem systemd durch einen Neustart mitgeteilt werden:

systemctl daemon-reload

Jetzt die Pfadstruktur für den chroot-Käfig erzeugen:

mkdir -p /var/bind9/chroot/{etc,dev,var/cache/bind,var/run/named}

Jetzt die speziellen Zugriffsrechte für bestimmte Pfade zuweisen:

mknod /var/bind9/chroot/dev/null c 1 3
mknod /var/bind9/chroot/dev/random c 1 8
chmod 660 /var/bind9/chroot/dev/{null,random}

Einschub für Debian 9: für random müssen die Zugriffsrechte mit folgendem Befehl korrekt gesetzt werden (ungetestet/danke Katharina für den Hinweis)

mknod /var/bind9/chroot/dev/urandom c 1 9

Jetzt die Konfigurationsdateien verschieben und Kompatibilität zum alten Platz gewährleisten:

mv /etc/bind /var/bind9/chroot/etc
ln -s /var/bind9/chroot/etc/bind /etc/bind

Weitere Anpassungen an den Zugriffsrechten:

chown -R bind:bind /etc/bind/*
chmod 775 /var/bind9/chroot/var/{cache/bind,run/named}
chgrp bind /var/bind9/chroot/var/{cache/bind,run/named}

In der Konfigurationsdatei /etc/init.d/bind9 den Pfad zur PID-Datei ändern:

PIDFILE=/var/bind9/chroot/var/run/named/named.pid

Dem syslog-daemon beibringen, dass er auf einem zusätzlichen Socket hören soll:

echo "\$AddUnixListenSocket /var/bind9/chroot/dev/log" > /etc/rsyslog.d/bind-chroot.conf

Jetzt kann der syslog-daemon neu gestartet und der bind9-daemon gestartet werden:

/etc/init.d/rsyslog restart; /etc/init.d/bind9 start

Update zu Debian 10 buster

Debian 10 buster aktiviert im Kernel automatisch apparmor. Damit läuft bind9 nicht mehr korrekt, da es über apparmor die Zugriffsrechte auf die Konfigurationsdateien verloren hat. Im Log sieht man folgende Meldungen:

…
open: /etc/bind/named.conf: permission denied
…

Entweder deinstalliert man apparmor (Reboot nicht vergessen, da sich apparmor im Kernel verewigt!), oder man passt die Konfigurationsdatei /etc/apparmor.d/local/usr.sbin.named:

/var/bind9/chroot/etc/bind/** r,
/var/bind9/chroot/var/** rw,
/var/bind9/chroot/dev/** rw,
/var/bind9/chroot/run/** rw,

Infos dazu gibt es auch im bind9 wiki von Debian.