[Eisfair] mail 1.17.2 - nach update -> keine locale mails mehr

[Marcus Röckrath]

Hallo Helmut,

Helmut Pohl wrote:

>>>>> 1.
>>>>> Die erste Station einer email (vom Laptop zum eis-mail-server) ist
>>>>> immer unverschlüsselt. Wenn ich den Thunderbird auf Verschlüsselung
>>>>> zum eis-mail-server setze, meldet er:
>>>>> "Senden der Nachricht fehlgeschlagen.
>>>>> Die Gegenstelle erkennt und traut der CA nicht, die Ihr Zertifikat
>>>>> ausgestellt hat.
>> 
>> Was ist hier mit Gegenstelle gemeint?
> 
> Die Gegenstelle von Thunderbird auf dem Laptop ist der eis-mail-server.
> Ist aber sehr komisch, dass der eis64 seinem eigenem CA-Zertifikat nicht
> traut, oder?! Es geht um die Kommunikation Thunderbird ->
> eisfair64-Mailserver

Ist das CA vielleicht abgelaufen.

Da müsste man wohl den Debug/Log-Level auf dem eis mal hochtreiben, denn 
wenn das sich auf den eis bezieht, was ich auch mit Gegenstelle verbinden 
würde, müsste das auch dort zu "loggen" sein.

> xen-test2 # tail -f /var/spool/exim/log/mainlog
> 
> 2026-02-15 23:59:06 Failed to open OCSP response file
> "/usr/local/ssl/crl/xen-test2.gallien.ocsp": NULL
> 2026-02-15 23:59:08 [192.168.1.11] SSL verify error: depth=0
> error=unable to get certificate CRL
> cert=/C=FR/ST=Vaucluse/L=Pernes-les-Fontaines/O=private/OU=eisfair/CN=xen-
test2.gallien/emailAddress=admin at eis64-home.gallien

Es geht hier aber erstmal um die CRL, was ich hier nach außen auch habe, 
aber die gesicherte Verbindung erstmal nicht verhindert:

[212.227.17.190] SSL verify error: depth=0 error=unable to get certificate 
CRL cert=/C=DE/ST=Rheinland-Pfalz/L=Montabaur/O=1&1 Mail & Media 
GmbH/CN=mail.gmx.net
[212.227.17.190] SSL verify error: depth=1 error=unable to get certificate 
CRL cert=/C=DE/O=Deutsche Telekom Security GmbH/CN=Telekom Security ServerID 
OV Class 2 CA
[212.227.17.190] SSL verify error: depth=2 error=unable to get certificate 
CRL cert=/C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust 
Center/CN=T-TeleSec GlobalRoot Class 2

aber die Übertragung geschieht über eine TLS-Verbindung:

=> xxx at abc.de R=smart_route T=remote_587 H=mail.gmx.net [212.227.17.190] 
X=TLS1.3:TLS_AES_256_GCM_SHA384:256 CV=no DN="/C=DE/ST=Rheinland-
Pfalz/L=Montabaur/O=1&1 Mail & Media GmbH/CN=mail.gmx.net" A=login_client 
C="250 Requested mail action okay, completed: id=...

> 2026-02-15 23:59:08 TLS error on connection from dell-inspiron.gallien
> [192.168.1.11] (SSL_accept): error:0A000086:SSL routines::certificate
> verify failed

Diese Zeile habe ich nie, verwende aber intern keine Verschlüsselung, müsste 
ich mal nachstellen.

Bitte poste mal aus dem certs-Menu die Details des exim.pem und des ca.pem.

>>>>> 2.
>>>>> Das Abholen der emails vom Provider-mail-server (z.B. gmx,arcor usw.)
>>>>> ist unverschlüsselt, obwohl Verschlüsselung konfiguriert. Das finde
>>>>> ich auch komisch. Deshalb meine Frage ist das so richtig, oder ist es
>>>>> ein Fehler, möglicherweise in meiner Konfiguration?
>>>>
>>>> Bitte poste Log-Informationen, die dies zeigen.
>>>>
>>>
>>> xen-test2 # tail -f /var/log/fetchmail.log
>>>
>>> fetchmail: forced manually at Sun, 15 Feb 2026 22:39:06 (CET)
>>> Feb 15 22:39:08 fetchmail: 340 messages (339 seen) for
>>> helmut_pohl at arcor.de at imap.arcor.de.
>>> Feb 15 22:39:09 fetchmail: reading message
>>> helmut_pohl at arcor.de@imap.vodafonemail.de:340 of 340 (4501 header
>>> octets) (3536 body octets) not flushed
>>> fetchmail: finished at Sun, 15 Feb 2026 22:39:09 (CET)
>>> fetchmail: starting fetchmail-loader script with 90 seconds delay
>> 
>> Wo steht da, dass die Verbindung zu arcor unverschlüsselt war. Über die
>> Art der Verbindung zu arcor steht doch da garnichts.
> 
> Stimmt, aber auch nicht das sie verschlüsselt war. Beim exim steht es
> explizit dabei.

Was hat da fetchmail mit exim zu tun?

Die Mailabholung beim externen Provider macht der fetchmal OHNE Beteiligung 
von exim. Lassen gmx und Co überhaupt noch unverschlüsselte Verbindungen zu?

> Woran kann man erkennen, dass die Kommunikation beim "email holen"
> verschlüsselt stattfindet?

Was genau bei der Mailabholung ausgehandelt wird, kannst du im verbose Mode 
sehen. In /usr/bin/fetchmail-loader setze MAIL_DO_DEBUG (Zeile 210) auf yes.

Dann sollte in /var/log&fetchmail eine Menge Infos drin stehen.

>> Das ist die interne Weiterleitung einer per fetchmail erhaltenen Mail an
>> den lokalen exim - was siehst du hier für ein Problem?
> 
> Ich sehe hier auch kein Problem, ist der Vollständigkeit halber beigefügt.

Ok, diese Verbindung ist übrigens IMMER unverschlüsselt.

-- 
Gruß Marcus
[eisfair-Team]