[Gelöst] Exim4 sendet nach Bullseye upgrade nicht mehr

[str]

Die Anmeldung am hat jahrelang gut funktioniert. Also: ja, selbstverständlich habe ich die korrekten Anmeldedaten hinterlegt.
Stellt sich aber die Frage, ob sich mit dem Upgrade auf Bullseye etwas am Anmelde-Standardverhalten bezüglich Plain/SSL/TLS/STARTTLS geändert hat.
Darüber habe ich nämlich nichts einschlägiges in den Dokumentationen gefunden.
Und mein Provider konnte mir in der Frage auch nicht weiterhelfen.

[bluestar]

Stellt sich aber die Frage, ob sich mit dem Upgrade auf Bullseye etwas am Anmelde-Standardverhalten bezüglich Plain/SSL/TLS/STARTTLS geändert hat.

Warum postest du nicht einfach mal deine komplette exim4.conf?

Mit exim4 -bV wird dir angezeigt wo sich die Datei befindet:

Code: Alles auswählen

Configuration file search path is /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /etc/exim4/exim4.conf

(So sieht die relevante Ausgabe bei mir aus)

[str]

Code: Alles auswählen

exim4 -bV
Exim version 4.94.2 #2 built 13-Jul-2021 16:04:57
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DANE DKIM DNSSEC Event I18N OCSP PIPE_CONNECT PRDR SOCKS TCP_Fast_Open
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
Configuration file search path is /etc/exim4/exim4.conf:/var/lib/exim4/config.autogenerated
Configuration file is /var/lib/exim4/config.autogenerated

pastebin/?mode=view&s=41547

Boah, ist die groß! Habe ich mir auch bisher nie angeschaut, sondern nur die kleine Konfigurationsdatei aus dem 1. Post.
Und außerdem hätte ich sie natürlich in /etc/exim4 vermutet

[bluestar]

pastebin/?mode=view&s=41547

Das sieht auf den ersten Blick auf jeden Fall nach einer korrekt generierten Config aus ... Auf der Basis wäre es gut, wenn du mal bitte die Rechte der Datei /etc/exim4/passwd.client und bitte prüfe auch mal den Inhalt der Datei, ob dort alles noch stimmig ist. Die Datei /etc/aliases solltest du auch mal inhaltstechnisch prüfen und wenn du uns noch einen Log-Auszug von /var/log/exim4/mainlog hier einstellen könntest, welche Zeilen dort generiert werden, wenn du eine Email versuchst zu versenden, dann kann das Debugging weitergehen.

[str]

Hat etwas gedauert, ich musste erstmal einiges anonymisieren.
Da stand ja sogar mein Remote Passwort im Klartext drin...

Debug Log eines fehlgeschlagenen Sendeversuches:
41557

[bluestar]

Debug Log eines fehlgeschlagenen Sendeversuches:
41557

Ich habe mir das ganze angesehen und kann dir eine Erklärung liefern, zuvor jedoch die passenden Stellen aus deinem Debug Output, beginnend bei Zeile 330)

Code: Alles auswählen

TLS: server cert verification includes hostname: "mail.meinedomain.de".
TLS: server certificate verification required.
TLS: will request OCSP stapling
about to gnutls_handshake
(TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
To get keying info for TLS1.3 is hard:
 Set environment variable SSLKEYLOGFILE to a filename relative to the spool directory,
 and make sure it is writable by the Exim runtime user.
 Add SSLKEYLOGFILE to keep_environment in the exim config.
 Start Exim as root.
 If using sudo, add SSLKEYLOGFILE to env_keep in /etc/sudoers
 (works for TLS1.2 also, and saves cut-paste into file).
 Trying to use add_environment for this will not work
TLS: checking peer certificate
TLS certificate verification failed: cert name mismatch
TLS session fail: (certificate verification failed)
  SMTP(close)>>

Zusammenfassend kann dein System das SSL Zertifikat des Mail-Servers, wo die Mails eingeliefert werden sollen, nicht validieren und daher fällt es auf die unverschlüsselte Übertragung zurück, wo standardmäßig keine Anmeldung versucht wird, ergo kommt es zum "Relaying Denied" Fehler.

[str]

Das heißt, ich muss die Zertifikatsdatei meines Providers bekommen und dann irgendwie in die exim Konfiguration importieren?

meinedomain.de und meinprovider.de sind natürlich Platzhalter, das meinte ich mit "Anonymisierung".
Den smarthost Namen von meinedomain.de in meinprovider.de zu ändern hatte ich schon mal versucht. Das hat nichts gebracht.
Ist es sinnvoll einen weiteren Versuch mit geändertem smarthost Namen und Debug-Ausgabe zu machen?

PS: Danke jedenfalls schon mal für die Unterstützung.

[bluestar]

Das heißt, ich muss die Zertifikatsdatei meines Providers bekommen und dann irgendwie in die exim Konfiguration importieren?

Nein das nützt dir nichts...

meinedomain.de und meinprovider.de sind natürlich Platzhalter, das meinte ich mit "Anonymisierung".

Letztlich musst du sicherstellen, dass der Servername, den du verwendest zu Namen im SSL-Zertifikat passt, sonst wird die SSL Validierung immer wieder fehlschlagen. Hier noch mal die genaue Fehlermeldung (Zeile: 345)

Code: Alles auswählen

TLS certificate verification failed: cert name mismatch

Ich hatte dir auch dazu noch eine PM mit weiteren Infos geschickt.

[str]

So, jetzt läufts!

Ich hatte ja, wie gesagt, den Namen des smarthosts schon mal geändert in den Namen meines Providers (anstelle des Namens, den er extra für mich angemeldet hat).
Die Fehlermeldung war aber anschließend dieselbe, weshalb ich das als Ursache ausgeschlossen hatte.
Nach dem Hinweis von bluestar, dass der Servername auch zum Zertifkatsinhaber passen muss, habe ich nochmal einen Sendeversuch mit Debug-Ausgabe gestartet.
Und siehe da: ich hätte den Servernamen auch in der Datei passwd.client ändern sollen

Dank an bluestar für die Hilfe!

Gruß
Stephan