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-       │                                                 │ I │
 │     null client      │                                                 │ N │
 ├──────────────────────┤                                                 │ T │
 │       Interne        │                                         ┌───────◄ E │
 │       clients        │                                         │       │ R │
 ├──────────────────────┤                                         │       │ N │
 │                      │                                         │       │ E │
 │  Relay: main client  │                                         │       │ T │
 │                      │                                         │       │   │
 └▼───▼───▼─────────────┘                                         │       └─▲─┘
  │   │   │                                                       │         │
  │   │   │   ┌───────────────────────────────────────────────────┘         │  
  │   │   │   │                                                             │
  │   │   │   │   ┌───────────────────────────────────────────┐             │
  │   │   │   │   │                  Postfix-                 │             │
  │   │   │   │   │                main server                │             │
  │   │   │   │   ├───────────────────────────────────────────┤             │
  │   │   │   │   │                                           │             │
  │   │   │   │   │   ┌───────────────────────────────────┐   │             │
  │   │   └───┴───┼───►  IN         Port:  25        OUT  │   │             │
  │   │           │   ├───────────────────────────────────┤   │             │
  │   │           │   │  ✔ interne E-Mail                 │   │             │
  │   │           │   │  ✘ externe E-Mail                 │   │             │
  │   │           │   │  ✔ Verschlüsselungen: möglich     │   │             │
  │   │           │   │  ✘ Authentifizierung: KEINE       │   │             │
  │   │           │   └───────────────────────────────────┘   │             │
  │   │           │                                           │             │
  │   │           │   ┌───────────────────────────────────┐   │             │
  │   └───────────┼───►  IN         Port: 465        OUT  ►───┼─────────────┤
  │               │   ├───────────────────────────────────┤   │             │
  │               │   │  ✔ interne E-Mail                 │   │             │
  │               │   │  ✔ externe E-Mail                 │   │             │
  │               │   │  ✔ Verschlüsselungen: möglich     │   │             │
  │               │   │  ✔ Authentifizierung: Zertifikat  │   │             │
  │               │   └───────────────────────────────────┘   │             │
  │               │                                           │             │
  │               │   ┌───────────────────────────────────┐   │             │
  └───────────────┼───►  IN         Port: 587        OUT  ►───┼─────────────┘
                  │   ├───────────────────────────────────┤   │
                  │   │  ✔ interne E-Mail                 │   │
                  │   │  ✔ externe E-Mail                 │   │
                  │   │  ✔ Verschlüsselungen: möglich     │   │
                  │   │  ✔ Authentifizierung: SASL        │   │
                  │   └───────────────────────────────────┘   │
                  │                                           │
                  │             'mx1.tachtler.net'            │
                  │                                           │
                  └─────────────────────┬─────────────────────┘
                                        │            
                            ┌───────────▼───────────┐
                            │                       │
                            │  'imap.tachtler.net'  │
                            │                       │
                            │  Port: 24             │
                            │  ✔ TLS-verschlüsselt  │
                            │  ✔ LMTP(s)-Transport  │
                            │                       │
                            └───────────────────────┘

Der Postfix-main server soll alle E-Mails an Dovecot: imap-tachtler.net über Port 24 und via TLS-Verschlüsselung weiterleiten.

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: main server
    • Postfix ArchLinux - Konfiguration: main server - TLS-Konfiguration
    • Postfix ArchLinux - Konfiguration: main server - DANE-Konfiguration
    • Postfix ArchLinux - Konfiguration: main server - smtps-Konfiguration
    • Postfix ArchLinux - Konfiguration: main server - SASL-Konfiguration

Für die nachfolgende Installation wird zusätzlich vorausgesetzt,

• dass eine lauffähige Version von Dovecot ab Version 2.3

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

• Dovecot ArchLinux
  • Dovecot ArchLinux - SSL/TLS
  • Dovecot ArchLinux - SASL
  • Dovecot ArchLinux - Quotas

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 = server.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 27380"; # 11.01.2025 - 30.12.2099
# Tachtler
# default: my $CADAYS = "-days 1095";   # 3 years
my $CADAYS = "-days 27381"; # 11.01.2025 - 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.lmtp-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: Jan 11 09:00:00 2025 GMT
            Not After : Dec 31 09:00:00 2099 GMT
        Subject:
            countryName               = DE
            stateOrProvinceName       = Bavaria (Bayern)
            organizationName          = tachtler.net
            commonName                = www.lmtp-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 Jan 11 10:00 cacert.pem
-rw-r--r-- 1 root root  1078 Jan 11 09:59 careq.pem
lrwxrwxrwx 1 root root    46 Jun 18  2024 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 Jan 11 09:59 crl
-rw-r--r-- 1 root root     3 Jan 11 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 Jan 11 10:00 index.txt
-rw-r--r-- 1 root root    21 Jan 11 10:00 index.txt.attr
-rw-r--r-- 1 root root     0 Jan 11 09:59 index.txt.old
drwxr-xr-x 1 root root    36 Jan 11 09:58 misc
drwxr-xr-x 1 root root    88 Jan 11 10:00 newcerts
-rw-r--r-- 1 root root 12475 Jan 11 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 Jan 11 09:59 private
-rw-r--r-- 1 root root  1279 Jun 18  2024 README
-rw-r--r-- 1 root root    41 Jan 11 10:00 serial

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

# ls -l /etc/ssl/private
total 4
-rw------- 1 root root 1862 Jan 11 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    = 27381         # how long to certify for 11.01.2025 - 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) []:server.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 Jan 11 10:13 /etc/ssl/newkey.pem
-rw-r--r-- 1 root root 1232 Jan 11 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: main server - Dovecot anbindung - 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: Jan 11 09:15:46 2025 GMT
            Not After : Dec 30 09:15:46 2099 GMT
        Subject:
            countryName               = DE
            stateOrProvinceName       = Bavaria (Bayern)
            localityName              = Munich (Muenchen)
            organizationName          = tachtler.net
            commonName                = server.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 Jan 11 10:16 /etc/ssl/newcert.pem
-rw------- 1 root root 1862 Jan 11 10:13 /etc/ssl/newkey.pem
-rw-r--r-- 1 root root 1232 Jan 11 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: main server - Dovecot anbindung - 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 Jan 11 10:19 /etc/ssl/key.pem
-rw------- 1 root root 1862 Jan 11 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/server.idmz.tachtler.net.key
# cp -a /etc/ssl/newcert.pem /etc/postfix/ssl/certs/server.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/server.idmz.tachtler.net.key /etc/postfix/ssl/certs/server.idmz.tachtler.net.pem /etc/postfix/ssl/certs/CAcert.pem > /etc/postfix/ssl/certs/server-lmtp-chain.pem 

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

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

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

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

und mit folgenden Befehlen die Dateirechte:

# chmod 400 /etc/postfix/ssl/private/server.idmz.tachtler.net.key
# chmod 444 /etc/postfix/ssl/certs/server.idmz.tachtler.net.pem
# chmod 444 /etc/postfix/ssl/certs/CAcert.pem
# chmod 440 /etc/postfix/ssl/certs/server-lmtp-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 50
-r--r--r-- 1 root root     4606 Jan 11 10:00 CAcert.pem
-r--r----- 1 root postfix 11306 Nov  3 19:23 server-chain.pem
-r-------- 1 root root    11306 Jan 11 10:47 server-lmtp-chain.pem
-r--r--r-- 1 root postfix  4996 Jan 11 10:16 server.idmz.tachtler.net.pem
-r--r--r-- 1 root root     4996 Nov  3 19:23 server.tachtler.net.pem

/etc/postfix/ssl/private:
total 4
-r-------- 1 root root 1704 Jan 11 10:19 server.idmz.tachtler.net.key
-r-------- 1 root root 1704 Nov  3 19:41 server.tachtler.net.key

Nach dem ein Root-Zertifikat wie hier: Postfix ArchLinux - Konfiguration: null client - Dovecot-Anbindung - 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.lmtp-tachtler.net.pem
-r--r--r-- 1 root root 1428 Jan 11 11:50 www.lmtp-tachtler.net.pem

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

• Postfix ArchLinux - Konfiguration: main server - Dovecot anbindung - Erstellen CA (Certificate Authority)

unter

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

eingegeben Namen.

WICHTIG - Bei der TLS-Konfiguration: lmtp 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 Dovecot (MDA) IMAP-Server via TLS/StartTLS-Verschlüsselung mittels „secure“ 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 LMTP-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#lmtp_tls_loglevel Postfix TLS Support
Defaultwert	lmtp_tls_loglevel = 0
Neuer Wert	lmtp_tls_loglevel = $smtp_tls_loglevel
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 lmtp_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.

lmtp_tls_mandatory_ciphers = medium 

lmtp_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.

lmtp_tls_ciphers = medium 

lmtp_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.

lmtp_tls_security_level = 

lmtp_tls_security_level = secure

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

Nachdem nun die Minimal-Konfigurationen in der Haupt-Konfigurationsdatei von Postfix durchgeführt wurden, ist es zwingend erforderlich die nachfolgende Frage noch zu beantworten:

• Wer soll die e-Mails, welche an den Benutzer root gerichtet sind, tatsächlich erhalten?

Dies ist aus zwei Gründen sehr wichtig

1. Verhinderung des Zugriffs durch andere Programme z.B. (Local Delivery agents) wie z.B. procmail
2. Verhinderung von Ausführung von Schadcode als Benutzer root

Standardmässig verwendet Postfix die Konfigurationsdatei

• /etc/postfix/aliases unter ArchLinux

um Weiterleitungen für lokale Benutzer, hier root zu realisieren.

Innerhalb dieser Konfigurationsdatei ist auch eine Weiterleitung von e-Mails an den lokalen Benutzer root und dessen Weiterleitung an einen mit nicht so umfangreichen Rechten ausgestatteter Benutzer vorbereitet:

(Nur relevanter Ausschnitt)

...
# Person who should get root's mail. Don't receive mail as root!
#root:      you

Hier sollte diese letzte Zeile z.B. wie folgt abgeändert werden:

# Person who should get root's mail. Don't receive mail as root!
# Tachtler
# default: #root:      you
root:      klaus@tachtler.net

ACHTUNG - In der Postfix-Konfiguration sollte die hier eingesetzte E-Mail-Adresse, hier z.B. klaus@tachtler.net - ein im Dovecot: imap-tachtler.net erstelltes Postfach sein!

Anschliessend ist sind die Änderungen erneut in ein für Postfix besser lesbares Datenbankformat umzuwandeln, was erstmals mit nachfolgendem Befehl durchgeführt werden kann:

# postalias /etc/postfix/aliases

bzw.

# newaliases

HINWEIS - Weitere Änderungen können dann mit dem Befehl newaliases durchgeführt werden!

HINWEIS - Es erfolgt keine Ausgabe, nach Befehlsausführung!

Abschliessend kann mit nachfolgendem Befehl überprüft werden, ob die Änderungen übernommen wurden:

# ls -l /etc/postfix/aliases*
-rw-r--r-- 1 root root 11084 Jan 11 11:41 /etc/postfix/aliases
-rw-r--r-- 1 root root 12288 Jab 11 12:42 /etc/postfix/aliases.lmdb

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
broken_sasl_auth_clients = yes
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
lmtp_tls_CApath = $smtp_tls_CApath
lmtp_tls_block_early_mail_reply = $smtp_tls_block_early_mail_reply
lmtp_tls_chain_files = ${config_directory}/ssl/certs/server-lmtp-chain.pem
lmtp_tls_ciphers = high
lmtp_tls_exclude_ciphers = $smtp_tls_exclude_ciphers
lmtp_tls_loglevel = $smtp_tls_loglevel
lmtp_tls_mandatory_ciphers = high
lmtp_tls_mandatory_exclude_ciphers = $smtp_tls_mandatory_exclude_ciphers
lmtp_tls_mandatory_protocols = $smtp_tls_mandatory_protocols
lmtp_tls_protocols = $smtp_tls_protocols
lmtp_tls_security_level = secure
lmtp_tls_wrappermode = yes
mailbox_transport = lmtp:inet:imap.tachtler.net:24
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain, server.idmz.$mydomain
myhostname = mx1.tachtler.net
mynetworks = 127.0.0.0/32 10.0.0.0/24 192.168.0.0/24 [::1]/128 [fd00:0:0:10::]/64 [fe80:0:0:10::]/64
 [fd00:0:0:192::]/64
myorigin = server.idmz.$mydomain
proxy_interfaces = 88.217.171.167
recipient_canonical_maps = lmdb:${config_directory}/recipient_canonical_maps
smtp_dns_support_level = dnssec
smtp_tls_CApath = ${config_directory}/ssl/certs
smtp_tls_block_early_mail_reply = yes
smtp_tls_chain_files = ${config_directory}/ssl/certs/server-chain.pem
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_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 = dane
smtp_tls_session_cache_database = lmdb:${data_directory}/smtp_scache
smtpd_sasl_auth_enable = yes
smtpd_sasl_local_domain = $mydomain
smtpd_sasl_path = inet:imap.tachtler.net:12345
smtpd_sasl_security_options = noanonymous, noplaintext
smtpd_sasl_tls_security_options = noanonymous
smtpd_sasl_type = dovecot
smtpd_tls_CApath = ${config_directory}/ssl/certs
smtpd_tls_ask_ccert = yes
smtpd_tls_auth_only = yes
smtpd_tls_chain_files = ${config_directory}/ssl/certs/server-chain.pem
smtpd_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
smtpd_tls_loglevel = 1
smtpd_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
smtpd_tls_mandatory_protocols = >=TLSv1.2, <=TLSv1.3
smtpd_tls_protocols = >=TLSv1.2, <=TLSv1.3
smtpd_tls_received_header = yes
smtpd_tls_security_level = may
smtpd_tls_session_cache_database = lmdb:${data_directory}/smtpd_scache
tls_append_default_CA = yes
tls_preempt_cipherlist = yes
tls_random_bytes = 255

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 Sat 2025-01-11 10:14:54 CET; 4s ago
 Invocation: 8017d2e374fb4f93a9cddc515121b5a1
    Process: 13867 ExecStart=/usr/bin/postfix start (code=exited, status=0/SUCC>
   Main PID: 13934 (master)
      Tasks: 3 (limit: 2315)
     Memory: 2.7M (peak: 4M)
        CPU: 292ms
     CGroup: /system.slice/postfix.service
             ├─13934 /usr/lib/postfix/bin/master -w
             ├─13935 pickup -l -t unix -u
             └─13936 qmgr -l -t unix -u

Jan 11 10:14:53 server systemd[1]: Starting Postfix Mail Transport Agent...
Jan 11 10:14:54 server postfix[13932]: postfix/postlog: starting the Postfix ma>
Jan 11 10:14:54 server postfix/postfix-script[13932]: starting the Postfix mail>
Jan 11 10:14:54 server postfix/master[13934]: daemon started -- version 3.9.1, >
Jan 11 10:14:54 server 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                 0.0.0.0:587       0.0.0.0:*    
 users:(("master",pid=13934,fd=21)) ino:62976 sk:3 cgroup:/system.slice/postfix.service <->
tcp   LISTEN 0      100                 0.0.0.0:25        0.0.0.0:*    
 users:(("master",pid=13934,fd=13)) ino:62967 sk:5 cgroup:/system.slice/postfix.service <->
tcp   LISTEN 0      100                 0.0.0.0:465       0.0.0.0:*    
 users:(("master",pid=13934,fd=25)) ino:62982 sk:6 cgroup:/system.slice/postfix.service <->
tcp   LISTEN 0      100                    [::]:587          [::]:*    
 users:(("master",pid=13934,fd=22)) ino:62977 sk:a cgroup:/system.slice/postfix.service v6only:1 <->
tcp   LISTEN 0      100                    [::]:25           [::]:*    
 users:(("master",pid=13934,fd=14)) ino:62968 sk:c cgroup:/system.slice/postfix.service v6only:1 <->
tcp   LISTEN 0      100                    [::]:465          [::]:*    
 users:(("master",pid=13934,fd=26)) ino:62983 sk:d cgroup:/system.slice/postfix.service v6only:1 <->

Anschliessend kann mit einem kleinen Test herausgefunden werden, ob lokal erzeugte e-Mails auch an Dovecot: imap-tachtler.net über Port 24 und via TLS-Verschlüsselung - zugestellt werden können, was ausnahmsweise mit nachfolgendem Befehl (und nicht mit telnet) durchgeführt werden soll:

# echo "Test-E-Mail (lmtp)" | /usr/sbin/sendmail root

Als Ergebnis sollten zwei Dinge kontrolliert werden:

1. Die Log-Einträge im systemd-journald
2. Der Inhalt sollte an Dovecot: imap-tachtler.net über Port 24 und via TLS-Verschlüsselung zugestellt werden.

Der Inhalte der Log-Einträge im systemd-journald sollte eine Ausgabe wie nachfolgend dargestellt ergeben, was mit nachfolgendem Befehl durchgeführt werden kann:

# journalctl -u postfix.service 

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

Jan 11 12:32:11 server postfix/pickup[13935]: 64190180084: uid=0 from=<root>
Jan 11 12:32:11 server postfix/cleanup[13983]: 64190180084:
 message-id=<20250111093211.64190180084@mx1.tachtler.net>
Jan 11 12:32:11 server postfix/qmgr[13936]: 64190180084: from=<root@server.idmz.tachtler.net>, size=275,
 nrcpt=1 (queue active)
Jan 11 12:32:11 server postfix/local[13990]: 64190180084: passing <klaus@tachtler.net> to transport=lmtp
Jan 11 12:32:11 server postfix/lmtp[13991]: Verified TLS connection established to
 imap.tachtler.net[10.0.0.80]:24: 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
Jan 11 12:32:11 server postfix/lmtp[13991]: 64190180084: to=<klaus@tachtler.net>, orig_to=<root>,
 relay=imap.tachtler.net[10.0.0.80]:24, delay=0.15, delays=0.05/0.01/0.07/0.03, dsn=2.0.0,
 status=sent (250 2.0.0 <klaus@tachtler.net> BVPgBJs6gmd3BQAAhuu2+w Saved)
Jan 11 12:32:11 server postfix/qmgr[13936]: 64190180084: removed

WICHTIG - Entscheidend ist, das im systemd-journald nachfolgender Eintrag zu finden ist:

Verified TLS connection established

Auf dem Dovecot: imap-tachtler.net sollte der Inhalte der Log-Einträge im systemd-journald eine Ausgabe wie nachfolgend dargestellt ergeben, was mit nachfolgendem Befehl durchgeführt werden kann:

# journalctl -u dovecot.service 

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

Jan 11 12:32:11 server dovecot[1384]: lmtp(1399): Connect from 10.0.0.60
Jan 11 12:32:11 server dovecot[1384]: lmtp(klaus@tachtler.net)<1399><BVPgBJs6gmd3BQAAhuu2+w>:
 msgid=<20250111093211.64190180084@mx1.tachtler.net>: saved mail to INBOX
Jan 11 12:32:11 server dovecot[1384]: lmtp(1399): Disconnect from 10.0.0.60: Logged out (state=READY)

Auf dem Dovecot: imap-tachtler.net kann der Inhalt der im mbox-Format angelegten Datei

• '/srv/vmail/tachtler.net/klaus/Maildir/new/1736587931.M109579P1399.server,S=634,W=649'

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

# cat /srv/vmail/tachtler.net/klaus/Maildir/new/1736587931.M109579P1399.server,S=634,W=649

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

# cat /srv/vmail/tachtler.net/klaus/Maildir/new/1736587931.M109579P1399.server,S=634,W=649
Return-Path: <root@server.idmz.tachtler.net>
Delivered-To: klaus@tachtler.net
Received: from mx1.tachtler.net ([10.0.0.60])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	by server.idmz.tachtler.net with LMTPS
	id BVPgBJs6gmd3BQAAhuu2+w
	(envelope-from <root@server.idmz.tachtler.net>)
	for <klaus@tachtler.net>; Sat, 11 Jan 2025 12:32:11 +0100
Received: by mx1.tachtler.net (Postfix, from userid 0)
	id 64190180084; Sat, 11 Jan 2025 12:32:11 +0100 (CET)
Message-Id: <20250111093211.64190180084@mx1.tachtler.net>
Date: Sat, 11 Jan 2025 12:32:11 +0100 (CET)
From: root@server.idmz.tachtler.net

Test-E-Mail (lmtp)

WICHTIG - Entscheidend ist, das im systemd-journald nachfolgender Eintrag zu finden ist:

with LMTPS