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

[str]

Moin Experten,

seit dem Upgrade zu Bullseye werden zu meinem Domain Hoster ausgehende E-Mails mit solchen Fehlermeldungen abgelehnt:

Code: Alles auswählen

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  empfaenger@gmx.de
    host mail.meinprovider.de [XX.XX.XX.XX]
    SMTP error from remote mail server after RCPT TO:<empfaenger@gmx.de>:
    554 5.7.1 <empfaenger@gmx.de>: Relay access denied


Reporting-MTA: dns; server.meinedomain.de

Action: failed
Final-Recipient: rfc822;empfaenger@gmx.de
Status: 5.0.0
Remote-MTA: dns; mail.meinprovider.de
Diagnostic-Code: smtp; 554 5.7.1 <empfaenger@gmx.de>: Relay access denied

In den apt changelogs habe ich zwar etwas gelesen von (sinngemäß) "will break existing setups", aber die weiteren Umstände habe ich nicht verstanden. Insbesondere nicht, wonach ich genau suchen soll und was dann ändern.
Der Hoster konnte mir auch nicht weiterhelfen.
Kann es hier jemand?

Meine (anonymisierte) update-exim4.conf.conf:

Code: Alles auswählen

dc_eximconfig_configtype='smarthost'
dc_other_hostnames='meinedomain.de'
dc_local_interfaces='127.0.0.1 ; ::1 ; 192.168.1.1'
dc_readhost='meinedomain.de'
dc_relay_domains=''
dc_minimaldns='true'
dc_relay_nets='192.168.1.0/24'
dc_smarthost='mail.meinprovider.de'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='mail_spool'

Danke für jeden Hinweis
Gruß
Stephan

[Blackbox]

update-exim4.conf.conf

Code: Alles auswählen

update-exim4.conf.conf

erscheint erst einmal ungewöhnlich.

[MSfree]

Code: Alles auswählen

update-exim4.conf.conf

erscheint erst einmal ungewöhnlich.

Das ist schon lange so. Das ist die Konfigurationsdatei, mit der das Skript /usr/sbin/update-exim4.conf die exim-Konfiguration generiert.

[Blackbox]

Das ist schon lange so.

Das kann durchaus sein, dennoch es sieht erst einmal falsch aus. - Zumindest für mich, der mit Exim nur aus der Ferne konfrontiert wird.

[str]

Ungewöhnlich mag sein. Falls es sich mit Bullseye zu falsch geändert hat, dann wüsste ich das gerne.
Ich spreche hier nicht von einer Konfiguration from scratch.
Seit der Umstellung auf exim4 (Lenny oder noch früher?) hat es ja immer funktioniert.

[Blackbox]

Seit der Umstellung auf exim4 (Lenny oder noch früher?) hat es ja immer funktioniert.

Wenn du wüsstest, wie oft ich diese Floskel in der Praxis zu hören bekomme. - Sinngemäß, aber gestern ging es noch ...

Ohne relevante Auszüge aus deinen Logfiles, werden wir dieses Problem nächste Woche immer noch diskutieren.

[bluestar]

In den apt changelogs habe ich zwar etwas gelesen von (sinngemäß) "will break existing setups", aber die weiteren Umstände habe ich nicht verstanden. Insbesondere nicht, wonach ich genau suchen soll und was dann ändern.

Kann es sein, dass du dich auf folgenden Abschnitt beziehst: https://www.debian.org/releases/bullsey ... ml#idm1468

[Blackbox]

Kann es sein, dass du dich auf folgenden Abschnitt beziehst: https://www.debian.org/releases/bullsey ... ml#idm1468

Das liest sich zumindest sehr nach dem geschildertem Exim Verhalten, gleichzeitig wird ein Lösungsweg angeboten.
Warten wir einmal, was der TO dazu sagt.

[str]

Kann es sein, dass du dich auf folgenden Abschnitt beziehst: https://www.debian.org/releases/bullsey ... ml#idm1468

Genau das meinte ich.
Das habe ich mir auch am Wochenende nochmal genau angeschaut und versucht irgendwie mit meiner Konfiguration zusammenzubringen.
Verstehe ich aber immer noch nicht, wo das für mich eventuell relevant wäre.
Die "unreinen Daten" betreffen doch nur die Ablage von ankommenden E-Mails?
Bei mir funktioniert aber die Weiterleitung der ausgehenden E-Mails nicht mehr.
Ich finde da keinen Bezug und den ganzen Text ziemlich unverständlich.
An der Übersetzung liegt es nicht, den Originaltext finde ich genauso verschwurbelt.
Bin ich denn der Einzige mit diesem Problem?
Oder der Einzige, der die Anweisungen nicht versteht?

[bluestar]

Genau das meinte ich.
Das habe ich mir auch am Wochenende nochmal genau angeschaut und versucht irgendwie mit meiner Konfiguration zusammenzubringen.

Hast du manuelle Anpassungen an der exim4.conf vorgenommen?

Verstehe ich aber immer noch nicht, wo das für mich eventuell relevant wäre.

Da du nun ein Minimum an Infos zu deiner Config rausgibst, stochern wir hier im Dunkel.

Bin ich denn der Einzige mit diesem Problem?
Oder der Einzige, der die Anweisungen nicht versteht?

Ohne Config Details kannst nur du diese Fragen beantworten.

[str]

Genau das meinte ich.
Das habe ich mir auch am Wochenende nochmal genau angeschaut und versucht irgendwie mit meiner Konfiguration zusammenzubringen.

Hast du manuelle Anpassungen an der exim4.conf vorgenommen?

Nein, die gepostete update-exim4.conf.conf hat dpkg-reconfigure so rausgelassen.

Verstehe ich aber immer noch nicht, wo das für mich eventuell relevant wäre.

Da du nun ein Minimum an Infos zu deiner Config rausgibst, stochern wir hier im Dunkel.

Welche Infos zu meiner Config? Was das Ziel ist?
Meine Linux- und Windows- Workstations mit Thunderbird senden ausgehende E-Mails zu meinem lokalen Server/ Gateway mit Debian Bullseye und exim4.
Dieser leitete sie dann bis zum Upgrade an den Mail-Server meines Domain-Hosters weiter (Smarthost) und sollte das auch weiterhin tun.
War das gemeint? Ich dachte, das ist die Standard-Anwendung überhaupt.

[bluestar]

Genau das meinte ich.
Das habe ich mir auch am Wochenende nochmal genau angeschaut und versucht irgendwie mit meiner Konfiguration zusammenzubringen.

Hast du manuelle Anpassungen an der exim4.conf vorgenommen?

Nein, die gepostete update-exim4.conf.conf hat dpkg-reconfigure so rausgelassen.

Schön das du meine Frage nicht gelesen hast…

[mludwig]

Der Mailserver deines Providers sagt, dass er nicht als "open relay" missbraucht werden will. Dass heisst dass du dich dort authentifizieren musst, um über diesen Mailserver senden zu dürfen, ansonsten nimmt der Mailserver des Providers nämlich nur Mails an, für die er selbst mx-Host ist.

Hast du denn Anmeldedaten für den Smarthost hinterlegt?

[bluestar]

Hast du denn Anmeldedaten für den Smarthost hinterlegt?

Soweit ich mich entsinne beinhaltet die Debian Standard Config keinen Support für den Versand via Smarthost mit Anmeldung.

[mludwig]

Hast du denn Anmeldedaten für den Smarthost hinterlegt?

Soweit ich mich entsinne beinhaltet die Debian Standard Config keinen Support für den Versand via Smarthost mit Anmeldung.

Das mag stimmen, lässt sich aber einbauen:
https://wiki.debian.org/Exim#Communicat ... _smarthost

[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