Postfix ist Wietse Venema's Mail-Server, welcher bei „IBM research“ als Alternative zum ehemals weit verbreiteten Programm Sendmail entwickelt wurde. Postfix erhebt den Anspruch ein schneller, einfach zu administrierender und sicherer Mail-Server zu sein.

Postfix wird von Wietse Venema entwickelt.

Ab hier werden zur Ausführung nachfolgender Befehle root-Rechte benötigt. Um der Benutzer root zu werden, melden Sie sich bitte als root-Benutzer am System an, oder wechseln mit nachfolgendem Befehl zum Benutzer root:

$ su -
Password:

Es soll für die Kommunikation via E-Mail mit Postfix nachfolgendes Konstrukt, wie in der gezeigten Skizze zu sehen ist, zum Einsatz kommen:

 ┌──────────────────────┐                 ┌──────────────────────┐        ┌───┐
 │       Postfix-       │                 │       Postfix-       │        │ I │
 │     null client      │                 │     main client      │        │ N │
 ├──────────────────────┤                 ├──────────────────────┤        │ T │
 │                      │     secure      │                      │  dane  │ E │
 │  Listen 'localhost'  ┼─────────────────►  Listen 'interface'  ┼────────► R │
 │  Cert 'self-signed'  │                 │  Cert 'officialone'  ◄────────┼ N │
 │                      │                 │                      │  may   │ E │
 │  Relay: main client  │                 │  'mx1.tachtler.net'  │        │ T │
 │                      │                 │                      │        │   │
 └──────────────────────┘                 └──────────────────────┘        └───┘

Damit der Postfix-null client via TLS/StartTLS-Verschlüsselung senden kann, muss zuerst ein Zertifikat erzeugt werden. Dabei soll ein sogenanntes Self-Signed-Certificate (Selbst erstelltes/unterschriebenes) Zertifikat zum Einsatz kommen.

Damit der Postfix-main client via TLS/StartTLS-Verschlüsselung senden und empfangen kann, ist ein Zertifikat von einer „offiziellen“ Zertifizierungsstelle erforderlich. Dies dient dann zur TLS/StartTLS-Verschlüsselung in beide Richtungen für eingehend und ausgehend.

Die interne Kommunikation vom Postfix-null client zum Postfix-main client soll via TLS/StartTLS-Verschlüsselung mittels „dane-only“ und später sogar „secure“ erzwungen werden.

Die externe Kommunikation vom und zum Postfix-main client via TLS/StartTLS-Verschlüsselung soll mittels „dane“ versucht werden.

Siehe auch nachfolgenden internen Link weiter unten:

• Postfix Archlinux - Konfiguration: null client - TLS-Konfiguration - TLS-Konfiguration: smtp

Für die nachfolgende Installation wird vorausgesetzt,

• dass eine lauffähige Version von Postfix ab Version 3.9

vorhanden ist und die unter nachfolgenden Links beschriebenen Installationen und Konfigurationen von Postfix als Mindestvoraussetzung zwingend durchgeführt wurden:

• Postfix ArchLinux
  • Postfix ArchLinux - Installation
  • Postfix ArchLinux - Minimal-Konfiguration
  • Postfix ArchLinux - Konfiguration: null client

Damit der Postfix-null client via TLS/StartTLS-Verschlüsselung senden kann, muss zuerst ein Zertifikat erzeugt werden. Dabei soll ein sogenanntes Self-Signed-Certificate (Selbst erstelltes/unterschriebenes) Zertifikat zum Einsatz kommen.

Um die Verschlüsselung einsetzen zu können, sind folgende Komponenten erforderlich:

• eine eigene Certificate Authority (CA), welche Self-Signed-Certificate (Selbst erstelltes/unterschriebenes) Zertifikat erstellen kann
• einen CSR (Certificate Request), welcher von einer Certificate Authority (CA) signiert wird
• einem private key (privaten Schlüssel), welcher zum CRT (Certificate) gehört und zum Einsatz eines CRT (Certificate) benötigt wird
• das CRT (Certificate) selbst, welcher von der Certificate Authority (CA) ausgestellt wird

Zur Erstellung eines Self-Signed-Certificate und zur Erstellung der oben genannten Komponenten, wird das Paket

• openssl

benötigt, welches i.d.R. bereits installiert sein sollte.

Abschliessend soll mit nachfolgendem Befehl in das Verzeichnis /etc/ssl gewechselt werden:

# cd /etc/ssl

Nachfolgende Anpassungen müssen mindestens in der Konfigurationsdatei /etc/ssl/openssl.cnf durchgeführt werden, um SAN (Subject Alternative Names) in das Zertifikat mit aufnehmen zu können:

# vim /etc/ssl/openssl.cnf

(Nur relevanter Ausschnitt):

[ v3_req ]
 
# Extensions to add to a certificate request
 
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# Tachtler - NEW -
subjectAltName = @alt_names
 
# Tachtler - NEW -
[ alt_names ]
DNS.1 = client.idmz.tachtler.net

Zur Erstellung einer eigene Certificate Authority (CA) kann ein Script, welches bei der Installation von openssl mitgeliefert wird und sich im Verzeichnis /etc/ssl/misc/ befindet, genutzt werden. Der Name des Scripts lautet

• /etc/ssl/misc/CA.pl.

HINWEIS - Um Subject Alternative Names hinzufügen zu können, muss nachfolgende zweite Ergänzung abgeändert werden, das sonst die -extensions v3_req NICHT angezogen wird!

HINWEIS - Die zu erstellende Certificate Authority (CA) hat standardmässig eine Laufzeit von 3 Jahren !!!

Falls eine längere Laufzeit als drei Jahre gewünscht sein soll, kann nachfolgender Parameter im Skript, in nachfolgendem Verzeichnis, mit nachfolgendem Namen

• /etc/ssl/misc/CA.pl

angepasst werden:

# vim /etc/ssl/misc/CA.pl

(Nur relevanter Ausschnitt)

...
# Tachtler
# default: my $DAYS = "-days 365";
my $DAYS = "-days 27451"; # 02.11.2024 - 30.12.2099
# Tachtler
# default: my $CADAYS = "-days 1095";   # 3 years
my $CADAYS = "-days 27452"; # 02.11.2024 - 31.12.2099
...
...
...
} elsif ($WHAT eq '-sign' ) {
    $RET = run("$CA -policy policy_anything -out $NEWCERT"
            # Tachtler
            # default: . " -infiles $NEWREQ $EXTRA{ca}");
            . " -extensions v3_req -infiles $NEWREQ $EXTRA{ca}");
    print "Signed certificate is in $NEWCERT\n" if $RET == 0;
... 

WICHTIG - Die Laufzeit der Certificate Authority (CA) muss länger als die Laufzeit des Zertifikates sein !!!

Folgender Aufruf erstellt eine eigene Certificate Authority (CA):

HINWEIS - Nicht benötigte Angaben werden mit Eingabe eines Punktes [.] übersprungen!

# /etc/ssl/misc/CA.pl -newca

# /etc/ssl/misc/CA.pl -newca
Directory /etc/ssl exists at /etc/ssl/misc/CA.pl line 163.
Directory /etc/ssl/certs exists at /etc/ssl/misc/CA.pl line 163.
Directory /etc/ssl/private exists at /etc/ssl/misc/CA.pl line 163.
CA certificate filename (or enter to create)
 
Making CA certificate ...
====
openssl req  -new -keyout /etc/ssl/private/cakey.pem -out /etc/ssl/careq.pem
..+.+........+....+..+....+..+++++++++++++++++++++++++++++++++++++++*........+...++++++++++++++++++++++++
+++++++++++++++*.......+.....+...+.......+...........+...+.+..............+......+.+...+..+....+...+..
+...............+....+.....+......+..........+...+..+......+...+.......+...+..+....+...+...+..+.+......
+.....+...+.+..+...+.+...........+.......+...............+.....+..........+........+...+.+...............
+.....+.+..+...............+.+............+........+.......+...+...........+..........+........+...+.....
+...+..+......+.+.....+.+...............+..+.+...........+.........+......+......+.........+.+.....
+..................+.......+........+.+.....+.+.................+.+..+...+.+...+..+...+.......+...+..
+.........+....+...+......................................+.+...+......+......+.....+.+..
+.....................+.+.........+.....+...................+..+...+.+......+..............+......+...+.
+.....+......+.............+........+.......+..+.........+.......+...+...........+....+..++++++
.....+.......+............+..+...+.+++++++++++++++++++++++++++++++++++++++*.....+...+.........+.......
+......+...............+++++++++++++++++++++++++++++++++++++++*......+....+...........+............+...
+.......+..+...+.......+......+.....+............+....+...+..+...+.+............+..+...+.......
+............+........+.+.................+...+.+.........+...............+...............+..+...
+...................+..+...+............+...+.+...........+...+......+...................+...+..+.+......
+...+..+...+.......++++++
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Bavaria (Bayern)
Locality Name (eg, city) []:Munich (Muenchen)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tachtler.net
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:www.tachtler.net
Email Address []:hostmaster@tachtler.net
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:.
==> 0
====
====
openssl ca  -create_serial -out /etc/ssl/cacert.pem -days 27452 -batch -keyfile /etc/ssl/private/cakey.pem
 -selfsign -extensions v3_ca -infiles /etc/ssl/careq.pem 
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for /etc/ssl/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            5e:bd:02:51:4b:c1:8e:a9:a8:c7:f0:4d:c1:02:45:82:da:96:0d:4e
        Validity
            Not Before: Nov  2 09:00:00 2024 GMT
            Not After : Dec 31 09:00:00 2099 GMT
        Subject:
            countryName               = DE
            stateOrProvinceName       = Bavaria (Bayern)
            organizationName          = tachtler.net
            commonName                = www.tachtler.net
            emailAddress              = hostmaster@tachtler.net
        X509v3 extensions:
            X509v3 Subject Key Identifier: 
                E3:65:CB:CC:6A:51:FC:B1:3B:70:ED:67:AA:E3:1E:F5:41:31:C4:BA
            X509v3 Authority Key Identifier: 
                E3:65:CB:CC:6A:51:FC:B1:3B:70:ED:67:AA:E3:1E:F5:41:31:C4:BA
            X509v3 Basic Constraints: critical
                CA:TRUE
Certificate is to be certified until Dec 31 09:00:00 2099 GMT (27452 days)
 
Write out database with 1 new entries
Database updated
==> 0
====
CA certificate is in /etc/ssl/cacert.pem

Durch ausführen des Skriptes mit nachfolgendem Aufrufparameter /etc/ssl/misc/CA.pl -newca ist eine neue Verzeichnisstruktur und neue Dateien unter

• /etc/ssl

entstanden, deren Inhalt mit nachfolgendem Befehl bequem aufgelistet werden kann:

# ls -l /etc/ssl
total 76
-rw-r--r-- 1 root root  4606 Nov  2 10:00 cacert.pem
-rw-r--r-- 1 root root  1078 Nov  2 09:59 careq.pem
lrwxrwxrwx 1 root root    46 Jun 18 20:36 cert.pem -> ../ca-certificates/extracted/tls-ca-bundle.pem
drwxr-xr-x 1 root root 15564 Oct 27 13:30 certs
drwxr-xr-x 1 root root     0 Nov  2 09:59 crl
-rw-r--r-- 1 root root     3 Nov  2 09:59 crlnumber
-rw-r--r-- 1 root root   412 Oct 23 09:12 ct_log_list.cnf
-rw-r--r-- 1 root root   412 Oct 23 09:12 ct_log_list.cnf.dist
-rw-r--r-- 1 root root   166 Nov  2 10:00 index.txt
-rw-r--r-- 1 root root    21 Nov  2 10:00 index.txt.attr
-rw-r--r-- 1 root root     0 Nov  2 09:59 index.txt.old
drwxr-xr-x 1 root root    36 Nov  2 09:58 misc
drwxr-xr-x 1 root root    88 Nov  2 10:00 newcerts
-rw-r--r-- 1 root root 12475 Nov  2 09:57 openssl.cnf
-rw-r--r-- 1 root root 12328 Oct 23 09:12 openssl.cnf.dist
drwxr-xr-x 1 root root    18 Nov  2 09:59 private
-rw-r--r-- 1 root root  1279 Jun 18 20:36 README
-rw-r--r-- 1 root root    41 Nov  2 10:00 serial

# ls -l /etc/ssl/newcerts
total 8
-rw-r--r-- 1 root root 4606 Nov  2 10:00 5EBD02514BC18EA9A8C7F04DC1024582DA960D4E.pem

# ls -l /etc/ssl/private
total 4
-rw------- 1 root root 1862 Nov  2 09:59 cakey.pem

Ebenfalls mit dem Script, welches schon bei der Erstellung einer eigene Certificate Authority (CA) genutzt wurde und sich unter /etc/ssl/misc befindet und den Namen CA trägt, kann nun dieses auch zur Erstellung von

• einem CSR (Certificate Request)
• einem private key (privaten Schlüssel)

genutzt werden.

HINWEIS - Das zu erstellende Zertifikat hat standardmässig eine Laufzeit von 1 Jahr !!!

Falls eine längere Laufzeit als ein Jahr gewünscht sein soll, kann nachfolgender Parameter im Skript, in nachfolgendem Verzeichnis, mit nachfolgendem Namen

• /etc/ssl/openssl.cnf

angepasst werden:

# vim /etc/ssl/openssl.cnf

(Nur relevanter Ausschnitt)

...
# Tachtler
# default: default_days = 365           # how long to certify for
default_days    = 27451         # how long to certify for 02.11.2024 - 30.12.2099
...

HINWEIS - Nicht benötigte Angaben werden mit Eingabe eines Punktes [.] übersprungen!

# /etc/ssl/misc/CA.pl -newreq -extra-req -extensions=v3_req

# /etc/ssl/misc/CA.pl -newreq -extra-req -extensions=v3_req
Use of uninitialized value $1 in concatenation (.) or string at /etc/ssl/misc/CA.pl line 151.
====
openssl req  -new  -keyout newkey.pem -out newreq.pem -days 27451  -extensions=v3_req
Warning: Ignoring -days without -x509; not generating a certificate
.+..+............+.+..+............+.......+...+..+..........+.....+.+..............+......++++++++++++++
+++++++++++++++++++++++++*........+.....+.......+......+..+.+.....+.......+..+.......+.....+.+........
+.......+++++++++++++++++++++++++++++++++++++++*....+......+.+.....+......+...+..........+...........+...
+.....+....+...+.....+..........+...+...............+.....+.+..............+.......+.....+............+...
+............+......+.........+.+......+.....+...................+...........+.+..+...+.......+..+.
+............+......+..+.............+.....+....+......+..+...+.........+.......+.....+...+......+....+..
+...+...+.......+......+.........+............+..............+.+.........+..+.......+..+.+.........
+..............+....+...+.........+...+..+......+............................+.....+....++++++
..+.........+...+....+.....+.........+................+..............++++++++++++++++++++++++++++++++++++
+++*.+.+..+++++++++++++++++++++++++++++++++++++++*.....+............+.+..+.+..+...
+..............................+....+.....+.+.........+..+.........+.+...+...+..+.+.........+..+.+...+...
+..........+......+.....+...+...+....+......+............+...............+..+.............+...+..+.......
+........+.+.....+.+........+...+...+......+................+...+..+............+.+......+...+.....+.....
+.......+.....+............+.+.....+......+....+.....+.+...........+.........+...................
+....................+.+...+...+...+..+..........+...+.....+......+..........+......+..+.......+......
+....................+.......+..+..........+...+......+.....+....+..+...+.....................+......
+..........+...+..+....+.....++++++
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Bavaria (Bayern)
Locality Name (eg, city) []:Munich (Muenchen)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:tachtler.net
Organizational Unit Name (eg, section) []:.
Common Name (e.g. server FQDN or YOUR name) []:client.idmz.tachtler.net
Email Address []:hostmaster@tachtler.net
 
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:.
==> 0
====
Request is in newreq.pem, private key is in newkey.pem

Durch ausführen des Scripts mit nachfolgendem Aufrufparameter /etc/ssl/misc/CA.pl -newreq -extra-req -extensions=v3_req sind zwei neue Dateien unter

• /etc/ssl

entstanden, welche mit nachfolgendem Befehl aufgelistet werden können:

# ls -l /etc/ssl/new*.pem
-rw------- 1 root root 1862 Nov  2 10:13 /etc/ssl/newkey.pem
-rw-r--r-- 1 root root 1232 Nov  2 10:13 /etc/ssl/newreq.pem

WICHTIG - Die so entstandene Datei /etc/ssl/newreq.pem enthält den CSR (Certificate Request).

Um den in obigen Beispiel entstandenen CSR (Certificate Request) nun mit der Certificate Authority (CA) zu unterschreiben und somit ein signiertes CRT (Certificate) zu erzeugen, kann wieder das Script, welches schon bei der Erstellung der Certificate Authority (CA) genutzt wurde und sich unter /etc/ssl/misc befindet und den Namen CA.pl trägt, mit nachfolgendem Befehl genutzt werden:

WICHTIG - Das Passwort, ist das Passwort, welches im Schritt Postfix ArchLinux - Konfiguration: null client - TLS-Konfiguration - Erstellen CA (Certificate Authority)

# /etc/ssl/misc/CA.pl -sign -extra-ca

# /etc/ssl/misc/CA.pl -sign -extra-ca
Use of uninitialized value in concatenation (.) or string at /etc/ssl/misc/CA.pl line 75.
====
openssl ca  -policy policy_anything -out newcert.pem -extensions v3_req -infiles newreq.pem  
Using configuration from /etc/ssl/openssl.cnf
Enter pass phrase for /etc/ssl/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
        Serial Number:
            5e:bd:02:51:4b:c1:8e:a9:a8:c7:f0:4d:c1:02:45:82:da:96:0d:4f
        Validity
            Not Before: Nov  2 09:15:46 2024 GMT
            Not After : Dec 30 09:15:46 2099 GMT
        Subject:
            countryName               = DE
            stateOrProvinceName       = Bavaria (Bayern)
            localityName              = Munich (Muenchen)
            organizationName          = tachtler.net
            commonName                = client.idmz.tachtler.net
            emailAddress              = hostmaster@tachtler.net
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            X509v3 Key Usage: 
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Alternative Name: 
                DNS:client.idmz.tachtler.net
Certificate is to be certified until Dec 30 09:15:46 2099 GMT (27451 days)
Sign the certificate? [y/n]:y
 
 
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Database updated
==> 0
====
Signed certificate is in newcert.pem

Durch ausführen des Skriptes mit nachfolgendem Aufrufparameter /etc/ssl/misc/CA.pl -sign -extra-ca ist eine weitere neue Dateien unter

• /etc/ssl

entstanden, welche mit nachfolgendem Befehl aufgelistet werden kann:

# ls -l /etc/ssl/new*.pem
-rw-r--r-- 1 root root 4996 Nov  2 10:16 /etc/ssl/newcert.pem
-rw------- 1 root root 1862 Nov  2 10:13 /etc/ssl/newkey.pem
-rw-r--r-- 1 root root 1232 Nov  2 10:13 /etc/ssl/newreq.pem

WICHTIG - Die so entstandene Datei /etc/ssl/newcert.pem enthält das neue signierte CRT (Certificate)!

Ein Problem ist durch die Erstellung der einzelnen Komponenten, wie in den drei vorhergehenden Schritten beschrieben worden noch offen.

WICHTIG - Der private key (privaten Schlüssel) ist mit einer Passphrase gesichert !

Um dieses Problem zu lösen und das Passwort aus dem private key (privaten Schlüssel) zu entfernen, kann folgender Aufruf von openssl genutzt werden:

WICHTIG - Das Passwort, ist das Passwort, welches im Schritt Postfix ArchLinux - Konfiguration: null client - TLS-Konfiguration - Erstellen CA (Certificate Authority)

# openssl rsa < /etc/ssl/newkey.pem > /etc/ssl/key.pem
Enter pass phrase: 
writing RSA key

Durch ausführen des oben genannten Befehls ist eine weitere neue Dateien unter

• /etc/ssl

entstanden, welche mit nachfolgendem Befehl aufgelistet werden kann:

# ls -l /etc/ssl/*key*
-rw-r--r-- 1 root root 1704 Nov  2 10:19 /etc/ssl/key.pem
-rw------- 1 root root 1862 Nov  2 10:13 /etc/ssl/newkey.pem

WICHTIG - Die so entstandene Datei /etc/ssl/key.pem enthält den private key (privaten Schlüssel) OHNE Passphrase!

Nach dem ein Zertifikat wie hier: Postfix ArchLinux - Konfiguration: null client - TLS-Konfiguration - TLS-Zertifikat erstellen beschrieben erstellt wurde, müssen die benötigen Komponenten noch an die entsprechenden Stellen im Betriebssystem kopiert werden. Dazu sind nachfolgende Befehle notwendig.

Bevor mit der abschliessenden Konfiguration von Postfix zur Nutzung von TLS-Verschlüssellung begonnen werden kann, sind die in den vorhergehenden Schritten erstellten Dateien:

• /etc/ssl/key.pem
• /etc/ssl/newcert.pem
• /etc/ssl/cacert.pem

noch zu kopieren, umzubenennen und zusammen zu fassen und die Besitz- und Dateirechte der entsprechend Dateien noch anzupassen!

Als erstes werden mit den nachfolgenden Befehlen zwei neue Verzeichnisse im bestehen Verzeichnis /etc/postfix angelegt:

# mkdir -p /etc/postfix/ssl/{certs,private}

Anschliessend werden mit den nachfolgenden Befehlen die entsprechenden Dateien an den jeweiligen Bestimmungsort kopiert und ggf. umbenannt:

# cp -a /etc/ssl/key.pem /etc/postfix/ssl/private/client.idmz.tachtler.net.key
# cp -a /etc/ssl/newcert.pem /etc/postfix/ssl/certs/client.idmz.tachtler.net.pem
# cp -a /etc/ssl/cacert.pem /etc/postfix/ssl/certs/CAcert.pem

Als nächstes soll nun aus dem

• private key (privaten Schlüssel)
• Self-Signed-Certificate (Selbst erstelltes/unterschriebenes) Zertifikat
• Certificate Authority (CA) Zertifikat

ein sogenannte chain (Ketten)-Datei erstellt werden, was mit nachfolgendem Befehl durchgeführt werden kann:

# cut -b 1- /etc/postfix/ssl/private/client.idmz.tachtler.net.key /etc/postfix/ssl/certs/client.idmz.tachtler.net.pem /etc/postfix/ssl/certs/CAcert.pem > /etc/postfix/ssl/certs/client-chain.pem 

Die Besitz- und Dateirechte der soeben kopieren und ggf. umbenannten Dateien

• /etc/postfix/ssl/private/client.idmz.tachtler.net.key
• /etc/postfix/ssl/certs/client.idmz.tachtler.net.pem
• /etc/postfix/ssl/certs/CAcert.pem
• /etc/postfix/ssl/certs/client-chain.pem

können mit folgenden Befehlen die Besitzrechte wie folgt korrigiert werden:

# chown root:root /etc/postfix/ssl/private/client.idmz.tachtler.net.key
# chown root:root /etc/postfix/ssl/certs/client.idmz.tachtler.net.pem
# chown root:root /etc/postfix/ssl/certs/CAcert.pem
# chown root:root /etc/postfix/ssl/certs/client-chain.pem

und mit folgenden Befehlen die Dateirechte:

# chmod 400 /etc/postfix/ssl/private/client.idmz.tachtler.net.key
# chmod 444 /etc/postfix/ssl/certs/client.idmz.tachtler.net.pem
# chmod 444 /etc/postfix/ssl/certs/CAcert.pem
# chmod 400 /etc/postfix/ssl/certs/client-chain.pem

Durch Ausführen der oben genannten Befehle sieht der Inhalt des Verzeichnisses

• /etc/postfix/ssl

wie folgt aus, welches mit nachfolgendem Befehl aufgelistet werden kann:

# ls -l /etc/postfix/ssl/*
/etc/postfix/ssl/certs:
total 28
-r--r--r-- 1 root root  4606 Nov  2 10:00 CAcert.pem
-r-------- 1 root root 11306 Nov  2 10:47 client-chain.pem
-r--r--r-- 1 root root  4996 Nov  2 10:16 client.idmz.tachtler.net.pem

/etc/postfix/ssl/private:
total 4
-r-------- 1 root root 1704 Nov  2 10:19 client.idmz.tachtler.net.key

Nach dem ein Root-Zertifikat wie hier: Postfix ArchLinux - Konfiguration: null client - TLS-Konfiguration - TLS-Zertifikat erstellen beschrieben ebenfalls erstellt wurde, kann und sollte dies zusätzlich auch noch in Archlinux integriert werden.

Die zu Archlinux hinzuzufügenden Root-Zertifikate werden dazu in nachfolgendes Verzeichnis

• /etc/ca-certificates/trust-source/anchors

wie folgt kopiert:

# cp -a /etc/postfix/ssl/certs/CAcert.pem /etc/ca-certificates/trust-source/anchors

Mit nachfolgendem Befehl, wird nun das zuvor kopierte Root-Zertifikat in Archlinux integriert:

# update-ca-trust

* Der Befehl erzeugt keine Ausgabe!

Ob das Root-Zertifikat nun in Archlinux integriert wurden, kann dadurch überprüft werden, ob sich das Root-Zertifikat in nachfolgendem Verzeichnis

• /etc/ca-certificates/extracted/cadir

befindet, was nach dem zuvor ausgeführtem Befehl, der Fall sein sollte und mit nachfolgendem Befehl überprüft werden kann:

# ls -la www.tachtler.net.pem
-r--r--r-- 1 root root 1428 Nov  3 05:50 www.tachtler.net.pem

HINWEIS - Der Name des Zertifikats, ergibt sich aus dem im Schritt

• Postfix ArchLinux - Konfiguration: null client - TLS-Konfiguration - Erstellen CA Certificate Authority

unter

• Common Name (e.g. server FQDN or YOUR name) []:www.tachtler.net

eingegeben Namen.

WICHTIG - Bei der TLS-Konfiguration: smtp handelt es sich um die verschlüsselte Kommunikation, bei der der Postfix (MTA) als client agiert!

Nachfolgend soll die interne Kommunikation vom Postfix-null client zum Postfix-main server via TLS/StartTLS-Verschlüsselung mittels „dane-only“ erzwungen werden.

Transport Layer Security (TLS, früher SSL genannt) bietet zertifikatsbasierte Authentifizierung und verschlüsselte Sitzungen. Eine verschlüsselte Sitzung schützt die Informationen, die mit SMTP-Mail oder mit SASL-Authentifizierung übertragen werden.

Ähnlich wie der Postfix SMTP-Server implementiert auch der Postfix SMTP/LMTP-Client mehrere TLS-Sicherheitsstufen. Diese Stufen werden in den folgenden Abschnitten ausführlicher beschrieben.

Stufe der Verschlüsselung	Beschreibung
none	Bei der TLS-Sicherheitsstufe „none“ ist die TLS-Verschlüsselung deaktiviert. Dies ist die Standardsicherheitsstufe und kann explizit durch die Einstellung smtp_tls_security_level = none konfiguriert werden. Für LMTP ist der entsprechende Parameter lmtp_tls_security_level = none zu verwenden. In diesem Fall wird TLS selektiv verwendet, d. h. nur bei Zielen, die ausdrücklich für TLS konfiguriert sind. Es kann TLS für eine Teilmenge von Zielen deaktiviert werden, während es für die übrigen Ziele aktiviert werden kann. In der Postfix-TLS-Richtlinientabelle ist die Sicherheitsstufe „none“ dafür anzugeben.
may	Auf der TLS-Sicherheitsstufe may ist die TLS-Verschlüsselung opportunistisch. Die SMTP-Transaktion wird verschlüsselt, wenn die STARTTLS ESMTP-Funktion vom Server unterstützt wird. Andernfalls werden die Nachrichten unverschlüsselt gesendet. Opportunistisches TLS kann durch die Einstellung smtp_tls_security_level = may konfiguriert werden. Für LMTP ist der entsprechende lmtp_tls_security_level = may-Parameter zu verwenden. Die Konfigurationsparameter smtp_tls_ciphers und smtp_tls_protocols (Postfix ≥ 2.6) bieten Kontrolle über die mit opportunistischem TLS verwendeten Verschlüsselungsgrade und Protokolle. Bei früheren Postfix-Versionen verwendet opportunistisches TLS immer den Verschlüsselungsgrad export und aktiviert alle Protokolle. Mit opportunistischem TLS wird die E-Mail-Zustellung auch dann fortgesetzt, wenn das Serverzertifikat nicht vertrauenswürdig ist oder den falschen Namen trägt. Wenn der TLS-Handshake bei einer opportunistischen TLS-Sitzung fehlschlägt, gibt der Postfix-SMTP-Client die E-Mail-Zustellung nicht auf, sondern wiederholt die Transaktion mit deaktiviertem TLS. Der Versuch einer unverschlüsselten Verbindung ermöglicht die Zustellung von E-Mails an Standorte mit nicht interoperablen Server-TLS-Implementierungen. HINWEIS - Opportunistische Verschlüsselung wird nie für LMTP über UNIX-Domänen-Sockets verwendet. Der Kommunikationskanal ist bereits ohne TLS vertraulich, so dass der einzige potenzielle Vorteil von TLS die Authentifizierung ist. Konfigurieren Sie kein opportunistisches TLS für LMTP-Übertragungen über UNIX-Domänen-Sockets. Es sollte TLS für LMTP über UNIX-Domänen-Sockets nur auf der Sicherheitsstufe encrypt oder höher definiert werden. Versuche, opportunistische Verschlüsselung von LMTP-Sitzungen zu konfigurieren, werden ignoriert und es wird eine Warnung in das E-Mail-Log geschrieben. Opportunistisches TLS kann nur für ausgewählte Ziele aktiviert werden. In der Postfix TLS-Richtlinientabelle ist die Sicherheitsstufe may anzugeben. Dies ist die gängigste Sicherheitsstufe für TLS-geschützte SMTP-Sitzungen. Eine höhere Sicherheitsstufe ist nicht allgemein verfügbar und wird, falls erforderlich, in der Regel nur für einzelne Ziele konfiguriert.
encrypt	Bei der TLS-Sicherheitsstufe encrypt werden Nachrichten nur über TLS-verschlüsselte Sitzungen gesendet. Die SMTP-Transaktion wird abgebrochen, es sei denn, die STARTTLS ESMTP-Funktion wird vom entfernten SMTP-Server unterstützt. Wenn keine geeigneten Server gefunden werden, wird die Nachricht zurückgestellt. Die obligatorische TLS-Verschlüsselung kann durch die Einstellung smtp_tls_security_level = encrypt konfiguriert werden. Obwohl die TLS-Verschlüsselung immer verwendet wird, erfolgt die Zustellung der Nachricht auch dann, wenn das Serverzertifikat nicht vertrauenswürdig ist oder einen falschen Namen trägt. Für LMTP ist der entsprechenden Parameter smtp_tls_security_level = encrypt zu verwenden. Ab dieser Sicherheitsstufe bestimmen die Konfigurationsparameter smtp_tls_mandatory_protocols und smtp_tls_mandatory_ciphers die Liste der ausreichend sicheren SSL-Protokollversionen und die minimale Chiffrierstärke. Wenn die Protokoll- oder Chiffrieranforderungen nicht erfüllt sind, wird die E-Mail-Transaktion abgebrochen. Die Dokumentation zu diesen Parametern enthält nützliche Interoperabilitäts- und Sicherheitsrichtlinien. Trotz des Potenzials, passive Lauschangriffe zu unterbinden, ist die obligatorische TLS-Verschlüsselung als Standardsicherheitsstufe für die E-Mail-Zustellung im öffentlichen Internet nicht praktikabel. Einige MX-Hosts unterstützen TLS überhaupt nicht, und einige derjenigen, die TLS unterstützen, haben fehlerhafte Implementierungen. Auf einem Host, der E-Mails an das Internet zustellt, sollten die obligatorische TLS-Verschlüsselung nicht als Standardsicherheitsstufe konfiguriert werden. Es kann die obligatorische TLS-Verschlüsselung nur für bestimmte Ziele aktivieren. Hier ist in der Postfix-TLS-Richtlinientabelle die Sicherheitsstufe „encrypt“ anzugeben.
dane	Der Postfix-SMTP-Client unterstützt zwei TLS-Sicherheitsstufen, die auf DANE-TLSA (RFC 6698, RFC 7671, RFC 7672)-Datensätzen basieren. Die opportunistische dane-Stufe und die obligatorische dane-only-Stufe. Die dane-Stufe ist eine stärkere Form des opportunistischen TLS, die gegen „Man in the Middle“- und „Downgrade“-Angriffe resistent ist, wenn die Zieldomäne DNSSEC verwendet, um DANE TLSA-Einträge für ihre MX-Hosts zu veröffentlichen. Wenn ein entfernter SMTP-Server über „brauchbare“ (siehe Abschnitt 3 von RFC 7672) DANE TLSA-Einträge verfügt, wird die Serververbindung authentifiziert. Wenn die DANE-Authentifizierung fehlschlägt, gibt es keinen Fallback zu unauthentifizierter oder Klartext-Zustellung. Wenn TLSA-Datensätze für einen bestimmten entfernten SMTP-Server veröffentlicht werden (was TLS-Unterstützung impliziert), aber alle aufgrund von nicht unterstützten Parametern oder fehlerhaften Daten „unbrauchbar“ sind, verwendet der Postfix-SMTP-Client obligatorisch unauthentifiziertes TLS. Andernfalls, wenn keine TLSA-Datensätze veröffentlicht werden, verhält sich der Postfix-SMTP-Client genauso wie bei may. HINWEIS - Weitere Informationen zu dane sind in nachfolgendem Abschnitt dane-only hinterlegt!
dane-only	Die dane-only-Stufe ist eine Form von Secure-Channel-TLS, die auf der DANE-PKI basiert. Wenn „brauchbare“ TLSA-Einträge vorhanden sind, werden diese zur Authentifizierung des entfernten SMTP-Servers verwendet. Andernfalls, oder wenn die Überprüfung des Serverzertifikats fehlschlägt, schlägt die Zustellung über den betreffenden Server fehl. Auf beiden Sicherheitsstufen wird die TLS-Richtlinie für das Ziel über TLSA-Einträge, die mit DNSSEC validiert wurden, eingeholt. Damit die TLSA-Richtlinie in Kraft treten kann, muss die DNS-Zone, die die Zieldomäne enthält, signiert sein, und das Betriebssystem des Postfix-SMTP-Clients muss so konfiguriert sein, dass es seine DNS-Abfragen an einen rekursiven DNS-Nameserver sendet, der in der Lage ist, die signierten Einträge zu validieren. Die DNS-Zone jedes MX-Hosts muss ebenfalls signiert sein und DANE-TLSA-Einträge (siehe Abschnitt 3 von RFC 7672) veröffentlichen, die angeben, wie das TLS-Zertifikat des MX-Hosts überprüft werden soll. TLSA-Einträge haben keinen Einfluss auf den normalen SMTP-MX-Host-Auswahlalgorithmus. Wenn einige MX-Hosts TLSA unterstützen und andere nicht, variiert die TLS-Sicherheit von Zustellung zu Zustellung. Es liegt in der Verantwortung des Domänenbesitzers, seine MX-Hosts und sein DNS sinnvoll zu konfigurieren. Um den Postfix-SMTP-Client für DNSSEC-Lookups zu konfigurieren, siehe die Dokumentation zum Parameter smtp_dns_support_level. Der Parameter tls_dane_digests steuert die Liste der unterstützten „Digests“. Wie in Abschnitt 3 von RFC 7672 erläutert, werden die Zertifikatsverwendungen „0“ und „1“, die das bestehende Web-PKI-Vertrauen „einschränken“ sollen, bei MTA-to-MTA-SMTP nicht unterstützt. Vielmehr werden TLSA-Datensätze mit den Verwendungen „0“ und „1“ als „unbrauchbar“ behandelt. Der Postfix SMTP-Client unterstützt nur die Zertifikatsverwendungen „2“ und „3“. Die experimentelle Unterstützung für das stille Mapping der Zertifikatsverwendung „1“ auf „3“ wurde mit Postfix 3.2 eingestellt. Wenn brauchbare TLSA-Datensätze für den entfernten SMTP-Server erhalten werden, sendet der Postfix SMTP-Client die SNI-TLS-Erweiterung in seiner SSL-Client-Helo-Nachricht. Dies kann dem entfernten SMTP-Server helfen, sein Versprechen einzulösen, ein Zertifikat bereitzustellen, das mit seinen TLSA-Einträgen übereinstimmt. Bei der Auswahl von Protokollen und Chiffren wird die Sicherheitsstufe dane wie eine „obligatorische“ TLS-Sicherheitsstufe behandelt, und schwache Chiffren und Protokolle werden deaktiviert. Da DANE Serverzertifikate authentifiziert, werden die aNULL-Cipher-Suiten auf dieser Stufe transparent ausgeschlossen, so dass dies nicht manuell konfiguriert werden muss. Die RFC 7672 (DANE) TLS-Authentifizierung ist mit Postfix Version 2.11 und höher verfügbar. Wenn ein DANE TLSA-Datensatz ein Trust-Anchor (TA)-Zertifikat (d.h. eine ausstellende CA) angibt, ist die Strategie zur Überprüfung des Peer-Namens des Server-Zertifikats unbedingt nexthop, hostname. Sowohl die nexthop-Domäne als auch der Hostname, die aus dem DNSSEC-validierten MX-Lookup stammen, sind fälschungssicher, und das Serverzertifikat muss mindestens einen dieser Namen enthalten. Wenn ein DANE TLSA-Datensatz ein End-Entity (EE)-Zertifikat angibt (d. h. das eigentliche Server-Zertifikat), werden, wie bei der nachstehenden Fingerprint-Sicherheitsstufe, keine Namensprüfungen oder Prüfungen des Zertifikatsablaufs durchgeführt. Das Serverzertifikat (oder sein öffentlicher Schlüssel) stimmt entweder mit dem DANE-Datensatz überein oder nicht. Serveradministratoren sollten solche EE-Datensätze bevorzugt vor allen anderen Typen veröffentlichen.
fingerprint	Auf der Sicherheitsstufe fingerprint werden keine vertrauenswürdigen Zertifizierungsstellen verwendet oder benötigt. Die Vertrauenskette des Zertifikats, das Ablaufdatum usw. werden nicht überprüft. Stattdessen listet der Parameter smtp_tls_fingerprint_cert_match oder das Attribut match in der Richtlinientabelle den fingerprint des Zertifikats oder des öffentlichen Schlüssels des entfernten SMTP-Servers auf. Die Überprüfung von Zertifikatsfingerabdrücken ist ab Postfix Version 2.5 verfügbar, die Unterstützung von fingerprint öffentlicher Schlüssel ist ab Postfix Version 2.9 verfügbar. Wenn Zertifikats-fingerprint sicher ausgetauscht werden, ist dies die stärkste, aber am wenigsten skalierbare Sicherheitsstufe. Es muss der fingerprint der X.509-Zertifikate jedes Peer-Servers sicher gesammelt werden, in einer lokalen Datei gespeichert und diese lokale Datei aktualisiert werden, wenn sich das öffentliche Zertifikat des Peer-Servers ändert. Wenn der fingerprint des öffentlichen Schlüssels anstelle des fingerprint des gesamten Zertifikats verwendet werden, bleibt der fingerprint auch nach der Erneuerung des Zertifikats gültig, vorausgesetzt, dass dieselben öffentlichen/privaten Schlüssel verwendet werden, um das neue Zertifikat zu erhalten. Die Überprüfung des fingerprint kann für ein SMTP-„VPN“, das eine kleine Anzahl von Zweigstellen über das Internet verbindet, oder für sichere Verbindungen zu einem zentralen Mail-Hub praktikabel sein. Sie funktioniert schlecht, wenn der entfernte SMTP-Server von einer dritten Partei verwaltet wird und sein öffentliches Zertifikat regelmässig ohne vorherige Abstimmung mit dem überprüfenden Standort geändert wird. Der zur Berechnung des Fingerabdrucks verwendete Digest-Algorithmus wird mit dem Parameter smtp_tls_fingerprint_digest ausgewählt. In der Richtlinientabelle können mehrere Fingerabdrücke mit einem „|“-Trennzeichen in einem einzigen Übereinstimmungsattribut kombiniert werden, oder es können mehrere Übereinstimmungsattribute verwendet werden. Das Zeichen „:“ wird nicht als Trennzeichen verwendet, da es zwischen jedem Paar von fingerprint-Ziffern (hexadezimal) steht. Der Standardalgorithmus ist sha256, wenn Postfix ≥ 3.6 und der Kompatibilitätslevel auf 3.6 oder höher gesetzt ist; bei Postfix ≤ 3.5 ist der Standardalgorithmus md5. Der bewährte Algorithmus ist nun sha256. Die jüngsten Fortschritte in der Kryptoanalyse von Hash-Funktionen haben dazu geführt, dass md5 und sha1 zugunsten von sha256 veraltet sind. Solange jedoch keine „Second-Pre-Image“-Angriffe gegen die älteren Algorithmen bekannt sind, ist ihre Verwendung in diesem Zusammenhang zwar nicht empfohlen, aber wahrscheinlich immer noch sicher.
verify	Bei der TLS-Sicherheitsstufe verify werden Nachrichten nur dann über TLS-verschlüsselte Sitzungen gesendet, wenn das Zertifikat des entfernten SMTP-Servers gültig ist (nicht abgelaufen oder widerrufen und von einer vertrauenswürdigen Zertifizierungsstelle signiert) und wenn der Name des Serverzertifikats einem bekannten Muster entspricht. Die obligatorische Überprüfung des Serverzertifikats kann durch die Einstellung smtp_tls_security_level = verify konfiguriert werden. Mit dem Parameter smtp_tls_verify_cert_match kann die Standardstrategie für den Abgleich des Zertifikatsnamens hostname ausser Kraft gesetzt werden. Die Feinabstimmung der Abgleichsstrategie ist im Allgemeinen nur für Ziele mit sicherem Kanal sinnvoll. Für LMTP kann der entsprechenden lmtp_tls_security_level = verify-Parameter verwendet werden. Wenn die Server-Zertifikatskette vertrauenswürdig ist (siehe smtp_tls_CAfile und smtp_tls_CApath), werden alle DNS-Namen in der Zertifikatserweiterung SubjectAlternativeName verwendet, um den Namen des entfernten SMTP-Servers zu überprüfen. Wenn keine DNS-Namen angegeben sind, wird der CommonName des Zertifikats überprüft. Mit Postfix ≥ 2.11 modifiziert der Parameter smtp_tls_trust_anchor_file oder typischerweise das entsprechende Attribut tafile pro Ziel optional die Überprüfung der Vertrauenskette. Wenn der Parameter nicht leer ist, wird den Root-CAs in CAfile und CApath nicht mehr vertraut. Stattdessen vertraut der Postfix-SMTP-Client nur den Zertifikatsketten, die von einem der in den ausgewählten Dateien enthaltenen Vertrauensanker signiert wurden. Die angegebenen Trust-Anchor-Zertifikate und öffentlichen Schlüssel unterliegen nicht dem Ablaufdatum und müssen keine (selbstsignierten) Root-CAs sein. Es kann, falls gewünscht, ein Zwischenzertifikate sein. Daher können sich diese Zertifikate auch „in der Mitte“ der vom entfernten SMTP-Server vorgelegten Vertrauenskette befinden, und alle nicht vertrauenswürdigen ausstellenden übergeordneten Zertifikate werden ignoriert. Trotz des Potenzials, „Man-in-the-Middle“- und andere Angriffe zu verhindern, ist die obligatorische Überprüfung der Vertrauenskette und des Betreffs nicht als Standardrichtlinie für die E-Mail-Zustellung im Internet praktikabel. Einige MX-Hosts unterstützen TLS überhaupt nicht, und ein großer Teil der TLS-fähigen MTAs verwendet selbstsignierte Zertifikate oder Zertifikate, die von einer privaten Zertifizierungsstelle signiert sind. Auf einem Rechner, der E-Mails ins Internet zustellt, sollten Sie die obligatorische Überprüfung von Serverzertifikaten nicht als Standardrichtlinie konfigurieren. Die obligatorische Überprüfung von Serverzertifikaten als Standardsicherheitsstufe kann sinnvoll sein, wenn Sie wissen, dass Sie nur Verbindungen zu Servern herstellen werden, die RFC 2487 unterstützen und über überprüfbare Serverzertifikate verfügen. Ein Beispiel wäre ein Client, der alle E-Mails an einen zentralen Mailhub sendet, der die erforderliche STARTTLS-Unterstützung bietet. In solchen Fällen können Sie stattdessen oft eine Secure-Channel-Konfiguration verwenden. Es kann die obligatorische Überprüfung von Serverzertifikaten nur für bestimmte Ziele aktiviert werden. Hier ist in der TLS-Richtlinientabelle von Postfix die Sicherheitsstufe verify anzugeben.
secure	Auf der secure TLS-Sicherheitsstufe werden Nachrichten nur über TLS-Sitzungen mit sicherem Kanal gesendet, bei denen die Überprüfung des DNS-Zertifikats auf Fälschungssicherheit erfolgreich war. Wenn keine geeigneten Server gefunden werden, wird die Nachricht zurückgestellt. Postfix Secure-Channels können durch die Einstellung smtp_tls_security_level = secure konfiguriert werden. Mit dem Parameter smtp_tls_secure_cert_match kann die Standardstrategie nexthop, dot-nexthop für den Zertifikatsabgleich ausser Kraft gesetzt werden. Für LMTP ist der entsprechenden lmtp_tls_security_level = secure-Parameter anzugeben. Wenn die Server-Zertifikatskette vertrauenswürdig ist (siehe smtp_tls_CAfile und smtp_tls_CApath), werden alle DNS-Namen in der Zertifikatserweiterung SubjectAlternativeName verwendet, um den Namen des entfernten SMTP-Servers zu überprüfen. Wenn keine DNS-Namen angegeben sind, wird der CommonName überprüft. Mit Postfix ≥ 2.11 modifiziert der Parameter smtp_tls_trust_anchor_file oder typischerweise das entsprechende Attribut tafile pro Ziel optional die Überprüfung der Vertrauenskette. Wenn der Parameter nicht leer ist, wird den Root-CAs in CAfile und CApath nicht mehr vertraut. Stattdessen vertraut der Postfix-SMTP-Client nur den Zertifikatsketten, die von einem der in den ausgewählten Dateien enthaltenen Vertrauensanker signiert wurden. Die angegebenen Trust-Anchor-Zertifikate und öffentlichen Schlüssel unterliegen nicht dem Ablaufdatum und müssen keine (selbst signierten) Root-CAs sein. Sie können, falls gewünscht, Zwischenzertifikate sein. Daher können sich diese Zertifikate auch „in der Mitte“ der vom entfernten SMTP-Server vorgelegten Vertrauenskette befinden, und alle nicht vertrauenswürdigen ausstellenden übergeordneten Zertifikate werden ignoriert. Trotz des Potenzials, „Man-in-the-Middle“- und andere Angriffe zu verhindern, ist die obligatorische Überprüfung von sicheren Serverzertifikaten als Standardrichtlinie für die E-Mail-Zustellung im Internet nicht praktikabel. Einige MX-Hosts unterstützen TLS überhaupt nicht, und ein grosser Teil der TLS-fähigen MTAs verwendet selbstsignierte Zertifikate oder Zertifikate, die von einer privaten Zertifizierungsstelle signiert sind. Auf einem Rechner, der E-Mails ins Internet zustellt, sollten Sie die sichere TLS-Verifizierung nicht als Standardrichtlinie konfigurieren. Die obligatorische Überprüfung von Serverzertifikaten als Standardsicherheitsstufe kann sinnvoll sein, wenn Sie wissen, dass Sie nur Verbindungen zu Servern herstellen werden, die RFC 2487 unterstützen und über überprüfbare Serverzertifikate verfügen. Ein Beispiel wäre ein Client, der alle E-Mails an einen zentralen Mailhub sendet, der die erforderliche STARTTLS-Unterstützung bietet. In solchen Fällen können Sie stattdessen oft eine Secure-Channel-Konfiguration verwenden. Es kann die obligatorische Überprüfung von Serverzertifikaten nur für bestimmte Ziele aktiviert werden. Hier ist in der TLS-Richtlinientabelle von Postfix die Sicherheitsstufe secure anzugeben.

Information	Beschreibung
Dokumentation	https://www.postfix.org/postconf.5.html#smtp_tls_loglevel Postfix TLS Support
Defaultwert	smtp_tls_loglevel = 0
Neuer Wert	smtp_tls_loglevel = 1
Beschreibung	Aktivierung der zusätzlichen Protokollierung der TLS-Aktivitäten des Postfix-SMTP-Clients. Jede Protokollierungsstufe umfasst auch die Informationen, die auf einer niedrigeren Protokollierungsstufe protokolliert werden. HINWEIS - Die Protokollierungsstufe smtp_tls_loglevel = 2 oder höher sollte nur im Falle von Problemen verwendet werden. Von der Verwendung von „Loglevel“ 4 wird dringend abgeraten.

Um zusätzliche Informationen über die TLS-Aktivitäten des Postfix-SMTP-Clients zu erhalten, kann das Loglevel von 0 bis 4 erhöht werden. Jede Protokollierungsstufe enthält auch die Informationen, die auf einer niedrigeren Protokollierungsstufe protokolliert werden.

smtp_tls_mandatory_ciphers = medium 

smtp_tls_mandatory_ciphers = high

Die nachfolgenden Verschlüsselungsgrade werden von Postfix unterstützt:

Grad	Beschreibung
high	Aktiviert nur OpenSSL-Verschlüsselungen der Stufe HIGH. Diese Einstellung kann sinnvoll sein, wenn alle obligatorischen TLS-Ziele (z. B. wenn alle E-Mails an einen entsprechend fähigen Relayhost weitergeleitet werden) mindestens eine Verschlüsselung der Stufe HIGH unterstützen. Die zugrundeliegende Chiffrierliste wird über den Konfigurationsparameter tls_high_cipherlist festgelegt, der nicht verändert werden sollte.
medium	Aktiviert nur OpenSSL-Verschlüsselungen der Stufe MEDIUM oder besser. Die zugrundeliegende Chiffrierliste wird über den Konfigurationsparameter tls_medium_cipherlist festgelegt, der nicht verändert werden sollten.
null	Aktiviert nur die NULL-OpenSSL-Chiffren, diese bieten Authentifizierung ohne Verschlüsselung. Diese Einstellung ist nur in dem seltenen Fall sinnvoll, dass alle Server darauf vorbereitet sind, NULL-Chiffren zu verwenden (normalerweise nicht in TLS-Servern aktiviert). Ein plausibler Anwendungsfall ist ein LMTP-Server, der an einem UNIX-Domänen-Socket lauscht, der so konfiguriert ist, dass er „NULL“-Chiffren unterstützt. Die zugrundeliegende Chiffrierliste wird über den Konfigurationsparameter tls_null_cipherlist festgelegt, der nicht verändert werden sollte.
low	Aktiviert OpenSSL-Verschlüsselungen der Stufe LOW oder stärker. In Postfix ≥ 3.8 ist dieser Verschlüsselungsgrad immer identisch mit MEDIUM. Neuere Versionen von OpenSSL unterstützen keine „LOW“-Chiffren mehr. In früheren Postfix -Versionen wurde die zugrundeliegende Chiffrierliste über den Konfigurationsparameter tls_low_cipherlist festgelegt, der nicht verändern sollten sollte. ACHTUNG - Dieser veraltete Cipher-Grad sollte NICHT verwendet werden.
export	Aktiviert EXPORT-Grad oder stärkere OpenSSL-Verschlüsselungen. In Postfix ≥ 3.8 ist dieser Verschlüsselungsgrad immer identisch mit MEDIUM. ACHTUNG - Neuere Versionen von OpenSSL unterstützen keine EXPORT-Chiffren mehr. In früheren Postfix -Versionen wurde die zugrundeliegende Chiffrierliste über den Konfigurationsparameter tls_export_cipherlist festgelegt, der nicht verändert werden sollten. ACHTUNG - Dieser veraltete Cipher-Grad sollte NICHT verwendet werden.

smtp_tls_ciphers = medium 

smtp_tls_ciphers = high

Die nachfolgenden Verschlüsselungsgrade werden von Postfix unterstützt:

Grad	Beschreibung
high	Aktiviert nur OpenSSL-Verschlüsselungen der Stufe HIGH. Diese Einstellung kann sinnvoll sein, wenn alle obligatorischen TLS-Ziele (z. B. wenn alle E-Mails an einen entsprechend fähigen Relayhost weitergeleitet werden) mindestens eine Verschlüsselung der Stufe HIGH unterstützen. Die zugrundeliegende Chiffrierliste wird über den Konfigurationsparameter tls_high_cipherlist festgelegt, der nicht verändert werden sollte.
medium	Aktiviert nur OpenSSL-Verschlüsselungen der Stufe MEDIUM oder besser. Die zugrundeliegende Chiffrierliste wird über den Konfigurationsparameter tls_medium_cipherlist festgelegt, der nicht verändert werden sollten.
null	Aktiviert nur die NULL-OpenSSL-Chiffren, diese bieten Authentifizierung ohne Verschlüsselung. Diese Einstellung ist nur in dem seltenen Fall sinnvoll, dass alle Server darauf vorbereitet sind, NULL-Chiffren zu verwenden (normalerweise nicht in TLS-Servern aktiviert). Ein plausibler Anwendungsfall ist ein LMTP-Server, der an einem UNIX-Domänen-Socket lauscht, der so konfiguriert ist, dass er „NULL“-Chiffren unterstützt. Die zugrundeliegende Chiffrierliste wird über den Konfigurationsparameter tls_null_cipherlist festgelegt, der nicht verändert werden sollte.
low	Aktiviert OpenSSL-Verschlüsselungen der Stufe LOW oder stärker. In Postfix ≥ 3.8 ist dieser Verschlüsselungsgrad immer identisch mit MEDIUM. Neuere Versionen von OpenSSL unterstützen keine „LOW“-Chiffren mehr. In früheren Postfix -Versionen wurde die zugrundeliegende Chiffrierliste über den Konfigurationsparameter tls_low_cipherlist festgelegt, der nicht verändern sollten sollte. ACHTUNG - Dieser veraltete Cipher-Grad sollte NICHT verwendet werden.
export	Aktiviert EXPORT-Grad oder stärkere OpenSSL-Verschlüsselungen. In Postfix ≥ 3.8 ist dieser Verschlüsselungsgrad immer identisch mit MEDIUM. ACHTUNG - Neuere Versionen von OpenSSL unterstützen keine EXPORT-Chiffren mehr. In früheren Postfix-Versionen wurde die zugrundeliegende Chiffrierliste über den Konfigurationsparameter tls_export_cipherlist festgelegt, der nicht verändert werden sollten. ACHTUNG - Dieser veraltete Cipher-Grad sollte NICHT verwendet werden.

smtp_tls_security_level = 

smtp_tls_security_level = dane-only

smtp_tls_security_level = may

HINWEIS - Parameter: smtp_tls_security_level

• Bis eine vollständige Konfiguration für dane-only durchgeführt wurde, soll aus Testzwecken der Parameter temporär auf may agbeändert werden!

Der Postfix SMTP/LMTP-Client implementiert mehrere TLS-Sicherheitsstufen. Diese Stufen werden in den folgenden Abschnitten ausführlicher beschrieben

WICHTIG - Bei der TLS-Konfiguration: tlsproxy handelt es sich um die verschlüsselte Kommunikation, bei der der Postfix (MTA) als proxy agiert!

Nachfolgend soll die interne Kommunikation vom Postfix-tlsproxy zum Postfix-null client via TLS/StartTLS-Verschlüsselung mittels „encrypt“ erzwungen werden.

Transport Layer Security (TLS, früher SSL genannt) bietet zertifikatsbasierte Authentifizierung und verschlüsselte Sitzungen. Eine verschlüsselte Sitzung schützt die Informationen, die mit SMTP-Mail oder mit SASL-Authentifizierung übertragen werden.

Ähnlich wie der Postfix SMTP/LMTP-Client implementiert auch der Postfix-tlsproxy mehrere TLS-Sicherheitsstufen. Diese Stufen werden in den folgenden Abschnitten ausführlicher beschrieben.

Stufe der Verschlüsselung	Beschreibung
none	Bei der TLS-Sicherheitsstufe „none“ ist die TLS-Verschlüsselung deaktiviert. Dies ist die Standardsicherheitsstufe und kann explizit durch die Einstellung smtpd_tls_security_level = none konfiguriert werden. In diesem Fall wird TLS selektiv verwendet, d. h. nur bei Zielen, die ausdrücklich für TLS konfiguriert sind. Es kann TLS für eine Teilmenge von Zielen deaktiviert werden, während es für die übrigen Ziele aktiviert werden kann. In der Postfix-TLS-Richtlinientabelle ist die Sicherheitsstufe „none“ dafür anzugeben.
may	Auf der TLS-Sicherheitsstufe may ist die TLS-Verschlüsselung opportunistisch. Die SMTP-Transaktion wird verschlüsselt, wenn die STARTTLS ESMTP-Funktion vom Server unterstützt wird. Andernfalls werden die Nachrichten unverschlüsselt gesendet. Opportunistisches TLS kann durch die Einstellung smtpd_tls_security_level = may konfiguriert werden. Mit opportunistischem TLS wird die E-Mail-Zustellung auch dann fortgesetzt, wenn das Serverzertifikat nicht vertrauenswürdig ist oder den falschen Namen trägt. Wenn der TLS-Handshake bei einer opportunistischen TLS-Sitzung fehlschlägt, gibt der Postfix-SMTP-Client die E-Mail-Zustellung nicht auf, sondern wiederholt die Transaktion mit deaktiviertem TLS. Der Versuch einer unverschlüsselten Verbindung ermöglicht die Zustellung von E-Mails an Standorte mit nicht interoperablen Server-TLS-Implementierungen. HINWEIS - Opportunistische Verschlüsselung wird nie für LMTP über UNIX-Domänen-Sockets verwendet. Der Kommunikationskanal ist bereits ohne TLS vertraulich, so dass der einzige potenzielle Vorteil von TLS die Authentifizierung ist. Opportunistisches TLS kann nur für ausgewählte Ziele aktiviert werden. In der Postfix TLS-Richtlinientabelle ist die Sicherheitsstufe may anzugeben. Dies ist die gängigste Sicherheitsstufe für TLS-geschützte SMTP-Sitzungen. Eine höhere Sicherheitsstufe ist nicht allgemein verfügbar und wird, falls erforderlich, in der Regel nur für einzelne Ziele konfiguriert.
encrypt	Bei der TLS-Sicherheitsstufe encrypt werden Nachrichten nur über TLS-verschlüsselte Sitzungen gesendet. Die SMTP-Transaktion wird abgebrochen, es sei denn, die STARTTLS ESMTP-Funktion wird vom entfernten SMTP-Server unterstützt. Wenn keine geeigneten Server gefunden werden, wird die Nachricht zurückgestellt. Die obligatorische TLS-Verschlüsselung kann durch die Einstellung smtpd_tls_security_level = encrypt konfiguriert werden. Obwohl die TLS-Verschlüsselung immer verwendet wird, erfolgt die Zustellung der Nachricht auch dann, wenn das Serverzertifikat nicht vertrauenswürdig ist oder einen falschen Namen trägt. Ab dieser Sicherheitsstufe bestimmen die Konfigurationsparameter smtpd_tls_mandatory_protocols und smtpd_tls_mandatory_ciphers die Liste der ausreichend sicheren SSL-Protokollversionen und die minimale Chiffrierstärke. Wenn die Protokoll- oder Chiffrieranforderungen nicht erfüllt sind, wird die E-Mail-Transaktion abgebrochen. Die Dokumentation zu diesen Parametern enthält nützliche Interoperabilitäts- und Sicherheitsrichtlinien. Trotz des Potenzials, passive Lauschangriffe zu unterbinden, ist die obligatorische TLS-Verschlüsselung als Standardsicherheitsstufe für die E-Mail-Zustellung im öffentlichen Internet nicht praktikabel. Einige MX-Hosts unterstützen TLS überhaupt nicht, und einige derjenigen, die TLS unterstützen, haben fehlerhafte Implementierungen. Auf einem Host, der E-Mails an das Internet zustellt, sollten die obligatorische TLS-Verschlüsselung nicht als Standardsicherheitsstufe konfiguriert werden. Es kann die obligatorische TLS-Verschlüsselung nur für bestimmte Ziele aktivieren. Hier ist in der Postfix-TLS-Richtlinientabelle die Sicherheitsstufe „encrypt“ anzugeben.

Information	Beschreibung
Dokumentation	https://www.postfix.org/postconf.5.html#tlsproxy_tls_security_level https://www.postfix.org/postconf.5.html#tls_random_source Postfix Connection Cache
Defaultwert	tlsproxy_tls_security_level = $smtpd_tls_security_level
Neuer Wert	tlsproxy_tls_security_level = encrypt
Beschreibung	Die SMTP-TLS-Sicherheitsstufe für den Postfix tlsproxy-Server; wenn ein nicht leerer Wert angegeben wird, überschreibt dieser die veralteten Parameter smtpd_use_tls und smtpd_enforce_tls. Siehe smtpd_tls_security_level für weitere Details. HINWEIS - Muss gesetzt werden, wenn verwendet wird. HINWEIS - Ein leerer Parameter wird mit nachfolgende Warnung im Log von Postfix quittiert: warning: TLS server role is disabled with tlsproxy_tls_security_level or tlsproxy_use_tls
Siehe auch	Postfix Archlinux - Konfiguration: null client - TLS-Konfiguration: smtp - smtp_tls_connection_reuse

WICHTIG - Da es sich hier um einen Postfix-null client handelt und dieser somit KEINE Postfix-main server - smtpd_tls_security_level Konfiguration besitzt, würde der Standardwert auf einen leeren Inhalt verweisen!

Deswegen ist es erforderlich, diesen Wert hier entsprechend, wie in nachfolgender Tabelle, welche die Postfix SMTP-Server TLS-Sicherheitsstufen beschreibt, zu setzen. Diese Stufen werden in den folgenden Abschnitten ausführlicher beschrieben.

Stufe der Verschlüsselung	Beschreibung
none	Bei der TLS-Sicherheitsstufe „none“ ist die TLS-Verschlüsselung deaktiviert. Dies ist die Standardsicherheitsstufe und kann explizit durch die Einstellung smtpd_tls_security_level = none konfiguriert werden. In diesem Fall wird TLS selektiv verwendet, d. h. nur bei Zielen, die ausdrücklich für TLS konfiguriert sind. Es kann TLS für eine Teilmenge von Zielen deaktiviert werden, während es für die übrigen Ziele aktiviert werden kann. In der Postfix-TLS-Richtlinientabelle ist die Sicherheitsstufe „none“ dafür anzugeben.
may	Auf der TLS-Sicherheitsstufe may ist die TLS-Verschlüsselung opportunistisch. Die SMTP-Transaktion wird verschlüsselt, wenn die STARTTLS ESMTP-Funktion vom Server unterstützt wird. Andernfalls werden die Nachrichten unverschlüsselt gesendet. Opportunistisches TLS kann durch die Einstellung smtpd_tls_security_level = may konfiguriert werden. Mit opportunistischem TLS wird die E-Mail-Zustellung auch dann fortgesetzt, wenn das Serverzertifikat nicht vertrauenswürdig ist oder den falschen Namen trägt. Wenn der TLS-Handshake bei einer opportunistischen TLS-Sitzung fehlschlägt, gibt der Postfix-SMTP-Client die E-Mail-Zustellung nicht auf, sondern wiederholt die Transaktion mit deaktiviertem TLS. Der Versuch einer unverschlüsselten Verbindung ermöglicht die Zustellung von E-Mails an Standorte mit nicht interoperablen Server-TLS-Implementierungen. HINWEIS - Opportunistische Verschlüsselung wird nie für LMTP über UNIX-Domänen-Sockets verwendet. Der Kommunikationskanal ist bereits ohne TLS vertraulich, so dass der einzige potenzielle Vorteil von TLS die Authentifizierung ist. Opportunistisches TLS kann nur für ausgewählte Ziele aktiviert werden. In der Postfix TLS-Richtlinientabelle ist die Sicherheitsstufe may anzugeben. Dies ist die gängigste Sicherheitsstufe für TLS-geschützte SMTP-Sitzungen. Eine höhere Sicherheitsstufe ist nicht allgemein verfügbar und wird, falls erforderlich, in der Regel nur für einzelne Ziele konfiguriert.
encrypt	Bei der TLS-Sicherheitsstufe encrypt werden Nachrichten nur über TLS-verschlüsselte Sitzungen gesendet. Die SMTP-Transaktion wird abgebrochen, es sei denn, die STARTTLS ESMTP-Funktion wird vom entfernten SMTP-Server unterstützt. Wenn keine geeigneten Server gefunden werden, wird die Nachricht zurückgestellt. Die obligatorische TLS-Verschlüsselung kann durch die Einstellung smtpd_tls_security_level = encrypt konfiguriert werden. Obwohl die TLS-Verschlüsselung immer verwendet wird, erfolgt die Zustellung der Nachricht auch dann, wenn das Serverzertifikat nicht vertrauenswürdig ist oder einen falschen Namen trägt. Ab dieser Sicherheitsstufe bestimmen die Konfigurationsparameter smtpd_tls_mandatory_protocols und smtpd_tls_mandatory_ciphers die Liste der ausreichend sicheren SSL-Protokollversionen und die minimale Chiffrierstärke. Wenn die Protokoll- oder Chiffrieranforderungen nicht erfüllt sind, wird die E-Mail-Transaktion abgebrochen. Die Dokumentation zu diesen Parametern enthält nützliche Interoperabilitäts- und Sicherheitsrichtlinien. Trotz des Potenzials, passive Lauschangriffe zu unterbinden, ist die obligatorische TLS-Verschlüsselung als Standardsicherheitsstufe für die E-Mail-Zustellung im öffentlichen Internet nicht praktikabel. Einige MX-Hosts unterstützen TLS überhaupt nicht, und einige derjenigen, die TLS unterstützen, haben fehlerhafte Implementierungen. Auf einem Host, der E-Mails an das Internet zustellt, sollten die obligatorische TLS-Verschlüsselung nicht als Standardsicherheitsstufe konfiguriert werden. Es kann die obligatorische TLS-Verschlüsselung nur für bestimmte Ziele aktivieren. Hier ist in der Postfix-TLS-Richtlinientabelle die Sicherheitsstufe „encrypt“ anzugeben.

Nachfolgende Änderungen sind in der Konfigurationsdatei /etc/postfix/master.cf erforderlich:

(Nur relevanter Ausschnitt):

# Tachtler
# default: #tlsproxy  unix  -       -       n       -       0       tlsproxy
tlsproxy  unix  -       -       n       -       0       tlsproxy

Hier wird die aus kommentierte Zeile, welchen den tlsproxy aktiviert ein kommentiert.

HINWEIS - Der tlsproxy ist erforderlich, weil der Parameter smtp_tls_connection_reuse = yes gesetzt wurde und die damit verbundene Funktionalität, dem Postfix Connection Cache von Postfix genutzt werden soll.

HIWNEIS - Falls der tlsproxy nicht zur Verfügung steht, wird dies mit nachfolgende Warnung im Log von Postfix quittiert:

• warning: connect to private/tlsproxy service: Connection refused

Siehe auch nachfolgenden externen Link:

• Postfix Connection Cache

Bevor der der postfix/master-Daemon/Dienst zum ersten mal gestartet werden soll, ist eine Überprüfung der korrekten Konfiguration der /etc/postfix/master.cf durch nachfolgenden Befehl, zu empfehlen

• postconf -M

und es sollte eine Ausgabe, in etwa wie die nachfolgend gezeigte erscheinen:

# postconf -M
smtp       inet  n       -       n       -       -       smtpd
tlsproxy   unix  -       -       n       -       0       tlsproxy
pickup     unix  n       -       n       60      1       pickup
cleanup    unix  n       -       n       -       0       cleanup
qmgr       unix  n       -       n       300     1       qmgr
tlsmgr     unix  -       -       n       1000?   1       tlsmgr
rewrite    unix  -       -       n       -       -       trivial-rewrite
bounce     unix  -       -       n       -       0       bounce
defer      unix  -       -       n       -       0       bounce
trace      unix  -       -       n       -       0       bounce
verify     unix  -       -       n       -       1       verify
flush      unix  n       -       n       1000?   0       flush
proxymap   unix  -       -       n       -       -       proxymap
proxywrite unix  -       -       n       -       1       proxymap
smtp       unix  -       -       n       -       -       smtp
relay      unix  -       -       n       -       -       smtp -o syslog_name=postfix/$service_name
showq      unix  n       -       n       -       -       showq
error      unix  -       -       n       -       -       error
retry      unix  -       -       n       -       -       error
discard    unix  -       -       n       -       -       discard
local      unix  -       n       n       -       -       local
virtual    unix  -       n       n       -       -       virtual
lmtp       unix  -       -       n       -       -       lmtp
anvil      unix  -       -       n       -       1       anvil
scache     unix  -       -       n       -       1       scache
postlog    unix-dgram n  -       n       -       1       postlogd

Falls vorstehende Änderungen durchgeführt wurden, sollte ein Neustart von Postfix nichts mehr im Wege stehen.

Bevor der der postfix/master-Daemon/Dienst zum ersten mal gestartet werden soll, ist eine Überprüfung der korrekten Konfiguration durch nachfolgenden Befehl, zu empfehlen

• postconf -n

und es sollte eine Ausgabe, in etwa wie die nachfolgend gezeigte erscheinen:

# postconf -n
alias_database = $alias_maps
alias_maps = lmdb:${config_directory}/aliases
compatibility_level = 3.9
debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin ddd $daemon_directory/$process_name
 $process_id & sleep 5
inet_interfaces = loopback-only
mydestination =
myhostname = client.idmz.tachtler.net
recipient_canonical_maps = lmdb:${config_directory}/recipient_canonical_maps
relayhost = tachtler.net
smtp_tls_CApath = ${config_directory}/ssl/certs
smtp_tls_block_early_mail_reply = yes
smtp_tls_chain_files = ${config_directory}/ssl/certs/client-chain.pem
smtp_tls_ciphers = high
smtp_tls_connection_reuse = yes
smtp_tls_exclude_ciphers = ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES256-SHA, DHE-RSA-AES256-GCM-SHA384,
 DHE-RSA-AES256-SHA256, DHE-RSA-AES256-SHA, ECDHE-RSA-CAMELLIA256-SHA384, DHE-RSA-CAMELLIA256-SHA256,
 DHE-RSA-CAMELLIA256-SHA, AES256-SHA256, AES256-SHA, CAMELLIA256-SHA256, CAMELLIA256-SHA,
 ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES128-SHA, DHE-RSA-AES128-SHA256, DHE-RSA-AES128-SHA,
 ECDHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA, AES128-SHA256,
 AES128-SHA, CAMELLIA128-SHA256, CAMELLIA128-SHA
smtp_tls_loglevel = 1
smtp_tls_mandatory_ciphers = high
smtp_tls_mandatory_exclude_ciphers = ECDHE-RSA-AES256-SHA384, ECDHE-RSA-AES256-SHA,
 DHE-RSA-AES256-GCM-SHA384, DHE-RSA-AES256-SHA256, DHE-RSA-AES256-SHA, ECDHE-RSA-CAMELLIA256-SHA384,
 DHE-RSA-CAMELLIA256-SHA256, DHE-RSA-CAMELLIA256-SHA, AES256-SHA256, AES256-SHA, CAMELLIA256-SHA256,
 CAMELLIA256-SHA, ECDHE-RSA-AES128-SHA256, ECDHE-RSA-AES128-SHA, DHE-RSA-AES128-SHA256,
 DHE-RSA-AES128-SHA, ECDHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA256, DHE-RSA-CAMELLIA128-SHA,
 AES128-SHA256, AES128-SHA, CAMELLIA128-SHA256, CAMELLIA128-SHA
smtp_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3
smtp_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtp_tls_security_level = may
smtp_tls_session_cache_database = lmdb:${data_directory}/smtp_scache
tls_append_default_CA = yes
tls_random_bytes = 255
tlsproxy_tls_CApath = $smtp_tls_CApath
tlsproxy_tls_ask_ccert = yes
tlsproxy_tls_chain_files = $smtp_tls_chain_files
tlsproxy_tls_ciphers = $smtp_tls_ciphers
tlsproxy_tls_exclude_ciphers = $smtp_tls_exclude_ciphers
tlsproxy_tls_loglevel = $smtp_tls_loglevel
tlsproxy_tls_mandatory_ciphers = $smtp_tls_mandatory_ciphers
tlsproxy_tls_mandatory_exclude_ciphers = $smtp_tls_mandatory_exclude_ciphers
tlsproxy_tls_mandatory_protocols = $smtp_tls_mandatory_protocols
tlsproxy_tls_protocols = $smtp_tls_protocols
tlsproxy_tls_security_level = encrypt

HINWEIS - Parameter: smtp_tls_security_level

• Bis eine vollständige Konfiguration für dane-only durchgeführt wurde, soll aus Testzwecken der Parameter temporär auf may agbeändert werden!

HINWEIS - die Konfiguration des postfix/master-Daemon/Dienst konnte korrekt gelesen werden, wenn die Konfiguration ohne Fehlermeldungen erscheint, was letztendlich zwar nicht bedeutet, das Sie auch korrekt ist, aber zumindest syntaktische Fehler ausschliesst !!!

Zuerst sollte nun der postfix-Server mit nachfolgendem Befehle neu gestartet werden:

# systemctl restart postfix.service

Mit nachfolgendem Befehl kann der Status des Postfix-Servers abgefragt werden:

# systemctl status postfix.service
● postfix.service - Postfix Mail Transport Agent
     Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; preset: >
     Active: active (running) since Sun 2024-11-17 16:01:26 CET; 5s ago
 Invocation: 4cc3cf1d038c498da95964d70b66e4c6
    Process: 6597 ExecStart=/usr/bin/postfix start (code=exited, status=0/SUCCE>
   Main PID: 6664 (master)
      Tasks: 3 (limit: 2315)
     Memory: 2.6M (peak: 4M)
        CPU: 272ms
     CGroup: /system.slice/postfix.service
             ├─6664 /usr/lib/postfix/bin/master -w
             ├─6665 pickup -l -t unix -u
             └─6666 qmgr -l -t unix -u

Nov 17 16:01:25 client systemd[1]: Starting Postfix Mail Transport Agent...
Nov 17 16:01:26 client postfix[6662]: postfix/postlog: starting the Postfix mai>
Nov 17 16:01:26 client postfix/postfix-script[6662]: starting the Postfix mail >
Nov 17 16:01:26 client postfix/master[6664]: daemon started -- version 3.9, con>
Nov 17 16:01:26 client systemd[1]: Started Postfix Mail Transport Agent.

Nachfolgender Befehl listet die IP-Adressen und die Ports auf, auf denen der Postfix-Server lauscht:

# ss -taubenp | grep postfix
tcp   LISTEN 0      100               127.0.0.1:25        0.0.0.0:*     users:(("master",pid=6664,fd=13))
ino:42758 sk:4 cgroup:/system.slice/postfix.service <->
tcp   LISTEN 0      100                   [::1]:25           [::]:*     users:(("master",pid=6664,fd=14))
ino:42759 sk:9 cgroup:/system.slice/postfix.service v6only:1 <->

Ein Test, ob die interne Kommunikation vom Postfix-null client zum Postfix-main client via TLS/StartTLS-Verschlüsselung und mittels „dane-only“ erzwungen wird, kann erst erfolgen, wenn die nachfolgenden Konfigurationen innerhalb des Konstrukts

• Postfix-null client
• Postfix-main server

ebenfalls durchgführt worden sind:

• Postfix ArchLinux
  • Postfix ArchLinux - Installation
  • Postfix ArchLinux - Minimal-Konfiguration
  • Postfix ArchLinux - Konfiguration: main server
    • Postfix Archlinux - Konfiguration: main server - TLS-Konfiguration

HINWEIS - Parameter: smtp_tls_security_level

• Bis eine vollständige Konfiguration für dane-only durchgeführt wurde, soll aus Testzwecken der Parameter temporär auf may abgeändert werden!

Anschliessend kann mit einem kleinen Test vom

• Postfix-null client

aus herausgefunden werden, ob lokal erzeugte e-Mails auch intern Zugestellt werden können, was ausnahmsweise mit nachfolgendem Befehl (und nicht mit telnet) durchgeführt werden soll:

# echo "Test E-Mail - TLS - null client und main server" | /usr/sbin/sendmail root

Als Ergebnis sollten zwei Dinge kontrolliert werden:

1. Die Log-Einträge im systemd-journald
2. Der Inhalt in der (falls nicht schon vorhandenen) neu im mbox-Format erstellten Datei /var/spool/mail/klaus

Der Inhalte der Log-Einträge im systemd-journald auf dem

• Postfix-null client

sollte eine Ausgabe wie nachfolgend dargestellt ergeben, was mit nachfolgendem Befehl durchgeführt werden kann:

# journalctl -u postfix*

wonach eine Ausgabe, in etwa wie die nachfolgend gezeigte erscheinen sollte: (Nur relevanter Ausschnitt):

Nov 23 06:56:01 client postfix/pickup[1577]: 009E288: uid=0 from=<root>
Nov 23 06:56:01 cleint postfix/cleanup[1647]: 009E288:
 message-id=<20241123055601.009E288@client.idmz.tachtler.net>
Nov 23 06:56:01 client postfix/qmgr[1579]: 009E288: from=<root@client.idmz.tachtler.net>, size=312,
 nrcpt=1 (queue active)
Nov 23 06:56:01 client postfix/tlsproxy[1656]: CONNECT to [10.0.0.60]:25
Nov 23 06:56:01 client postfix/tlsproxy[1656]: Trusted TLS connection established to
 10.0.0.60[10.0.0.60]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519
 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits)
 client-digest SH>
Nov 23 06:56:01 client postfix/smtp[1654]: Trusted TLS connection established to
 10.0.0.60[10.0.0.60]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519
 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits)
 client-digest SHA256
Nov 23 06:56:01 client postfix/smtp[1654]: 009E288: to=<root@tachtler.net>, orig_to=<root>,
 relay=10.0.0.60[10.0.0.60]:25, delay=0.19, delays=0.04/0.04/0.1/0.02, dsn=2.0.0, status=sent (250 2.0.0
 Ok: queued as 639F8180089)
Nov 23 06:56:01 client postfix/tlsproxy[1656]: DISCONNECT [10.0.0.60]:25
Nov 23 06:56:01 client postfix/qmgr[1579]: 009E288: removed

Der Inhalte der Log-Einträge im systemd-journald auf dem

• Postfix-main server

sollte eine Ausgabe wie nachfolgend dargestellt ergeben, was mit nachfolgendem Befehl durchgeführt werden kann:

# journalctl -u postfix*

wonach eine Ausgabe, in etwa wie die nachfolgend gezeigte erscheinen sollte: (Nur relevanter Ausschnitt):

Nov 23 06:56:01 server postfix/smtpd[5279]: connect from cleint.idmz.tachtler.net[10.0.0.80]
Nov 23 06:56:01 server postfix/smtpd[5279]: Trusted TLS connection established from
 client.idmz.tachtler.net[10.0.0.80]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS
 (2048 bits) clien>
Nov 23 06:56:01 server postfix/smtpd[5279]: 639F8180089: client=client.idmz.tachtler.net[10.0.0.80]
Nov 23 06:56:01 server postfix/cleanup[5283]: 639F8180089:
 messageid=<20241123055601.009E288@vml080.idmz.tachtler.net>
Nov 23 06:56:01 server postfix/smtpd[5279]: disconnect from client.idmz.tachtler.net[10.0.0.80] ehlo=2
 starttls=1 mail=1 rcpt=1 data=1 quit=1 commands=7
Nov 23 06:56:01 server postfix/qmgr[5259]: 639F8180089: from=<root@client.idmz.tachtler.net>, size=803,
 nrcpt=1 (queue active)
Nov 23 06:56:01 server postfix/local[5284]: 639F8180089: to=<klaus@server.idmz.tachtler.net>,
 orig_to=<root@tachtler.net>, relay=local, delay=0.02, delays=0.01/0.01/0/0, dsn=2.0.0, status=sent
 (delivered to mailbox)
Nov 23 06:56:01 server postfix/qmgr[5259]: 639F8180089: removed

WICHTIG - Die E-Mail liegt nicht auf dem „null client“, sondern auf dem unter relayhost definierten Ziel!

Auf dem „main server“ kann der Inhalt der im mbox-Format angelegten Datei /var/spool/mail/klaus angesehen werden und sollte ebenfalls eine Ausgabe wie nachfolgend dargestellt ergeben, was mit nachfolgendem Befehl durchgeführt werden kann:

# cat /var/spool/mail/klaus

wonach eine Ausgabe, in etwa wie die nachfolgend gezeigte erscheinen sollte:

# cat /var/spool/mail/klaus
From root@client.idmz.tachtler.net  Sat Nov 23 06:56:01 2024
Return-Path: <root@client.idmz.tachtler.net>
X-Original-To: root@tachtler.net
Delivered-To: root@tachtler.net
Received: from client.idmz.tachtler.net (client.idmz.tachtler.net [10.0.0.80])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	 key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256
	 client-signature RSA-PSS (2048 bits) client-digest SHA256)
	(Client CN "client.idmz.tachtler.net", Issuer "www.tachtler.net" (verified OK))
	by mx1.tachtler.net (Postfix) with ESMTPS id 639F8180089
	for <root@tachtler.net>; Sat, 23 Nov 2024 06:56:01 +0100 (CET)
Received: by client.idmz.tachtler.net (Postfix, from userid 0)
	id 009E288; Sat, 23 Nov 2024 06:56:00 +0100 (CET)
Message-Id: <20241123055601.009E288@client.idmz.tachtler.net>
Date: Sat, 23 Nov 2024 06:56:00 +0100 (CET)
From: root@client.idmz.tachtler.net
 
Test E-Mail - TLS - null client und main server

Nachfolgende weiterführende Konfigurationen unter nachfolgenden internen Links, müssen ebenfalls noch durchgeführt werden:

• Postfix ArchLinux - Konfiguration: null client - DANE-Konfiguration