Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #5599 > unrolled thread

fetchmail mit gmx

Started byAnton Blau <tony.blue@gmx.de>
First post2017-01-06 21:13 +0100
Last post2017-01-15 00:07 +0100
Articles 6 — 3 participants

Back to article view | Back to de.comm.software.mailserver

Contents

  fetchmail mit gmx Anton Blau <tony.blue@gmx.de> - 2017-01-06 21:13 +0100
    Re: fetchmail mit gmx Andreas Kohlbach <ank@spamfence.net> - 2017-01-06 17:03 -0500
      Re: fetchmail mit gmx Matthias Andree <matthias.andree@gmx.de> - 2017-01-08 21:44 +0100
    Re: fetchmail mit gmx Matthias Andree <matthias.andree@gmx.de> - 2017-01-08 21:44 +0100
      Re: fetchmail mit gmx Anton Blau <tony.blue@gmx.de> - 2017-01-11 13:42 +0100
        Re: fetchmail mit gmx Matthias Andree <matthias.andree@gmx.de> - 2017-01-15 00:07 +0100

#5599 — fetchmail mit gmx

FromAnton Blau <tony.blue@gmx.de>
Date2017-01-06 21:13 +0100
Subjectfetchmail mit gmx
Message-ID<o4otq7$1d69$1@adenine.netfront.net>
Hallo,

ich hole für mehrere User per fetchmail Mails auf meinen lokalen 
dovecot. Leider erhalte ich immer für den letzten User im "poll"-Block 
diese Fehlermeldungen:

...
fetchmail: fetchmail 6.3.26 Dämon wird gestartet
fetchmail: 1 Nachricht für user1@gmx.de bei pop.gmx.net (10824 Bytes).
fetchmail: Nachricht user1@gmx.de@pop.gmx.net:1 von 1 wird gelesen 
(10824 Bytes) gelöscht
fetchmail: Fehler bei Server-Zertifikat-Überprüfung: self signed 
certificate in certificate chain
fetchmail: Fehlendes Zertifikat als Vertrauensquelle: /C=DE/O=Deutsche 
Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
fetchmail: Das kann bedeuten, dass das Wurzelzertifikat nicht unter den 
vertrauenswürdigen CA-Zertifikaten ist, oder dass c_rehash auf dem 
Verzeichnis ausgeführt werden muss. Details sind in der 
fetchmail-Handbuchseite im bei --sslcertpath beschrieben.
fetchmail: OpenSSL berichtete: error:14090086:SSL 
routines:ssl3_get_server_certificate:certificate verify failed
fetchmail: SSL-Verbindung fehlgeschlagen.
fetchmail: Socket-Fehler beim Abholen von user3@pop.gmx.net
fetchmail: Abfragestatus=2 (SOCKET)
...

Hier die /etc/fetchmailrc

set postmaster "postmaster"
set nobouncemail
set logfile /var/log/mail/fetchmail.log
defaults
bad-header accept

poll pop.gmx.net with proto pop3
       user 'user1@gmx.de' there with password 'pwuser1' is 'localuser1' 
here ssl
      user 'user2@gmx.net' there with password 'pwuser2' is 'localuser2' 
here ssl
       user 'user3@gmx.de' there with password 'psuser3' is 'localuser3' 
here ssl

sslfingerprint "34:28:34:E3:72:21:BF:1C:B4:FA:28:C8:BD:C2:E3:23"
       sslcertck
       sslcertpath /etc/ssl/fetchmaild/certs/


poll pop3.web.de with proto POP3
       user 'user4@web.de' there with password 'pwuser4' is 'localuser4' 
here ssl
       sslfingerprint "3A:66:38:66:C1:2A:5C:7D:AC:62:88:EF:0A:69:AA:C5"
       sslproto ssl23
       sslcertpath /etc/ssl/fetchmaild/certs/


Wie löse ich das?

Vielen Dank!


Tony

[toc] | [next] | [standalone]

#5600

FromAndreas Kohlbach <ank@spamfence.net>
Date2017-01-06 17:03 -0500
Message-ID<877f67yhg2.fsf@usenet.ankman.de>
In reply to#5599
On Fri, 6 Jan 2017 21:13:57 +0100, Anton Blau wrote:
>
> Hallo,
>
> ich hole für mehrere User per fetchmail Mails auf meinen lokalen
> dovecot. Leider erhalte ich immer für den letzten User im "poll"-Block
> diese Fehlermeldungen:
>
> ...
> fetchmail: fetchmail 6.3.26 Dämon wird gestartet
> fetchmail: 1 Nachricht für user1@gmx.de bei pop.gmx.net (10824 Bytes).
> fetchmail: Nachricht user1@gmx.de@pop.gmx.net:1 von 1 wird gelesen
> (10824 Bytes) gelöscht
> fetchmail: Fehler bei Server-Zertifikat-Überprüfung: self signed
> certificate in certificate chain
> fetchmail: Fehlendes Zertifikat als Vertrauensquelle: /C=DE/O=Deutsche
> Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
> fetchmail: Das kann bedeuten, dass das Wurzelzertifikat nicht unter
> den vertrauenswürdigen CA-Zertifikaten ist, oder dass c_rehash auf dem
> Verzeichnis ausgeführt werden muss. Details sind in der
> fetchmail-Handbuchseite im bei --sslcertpath beschrieben.
> fetchmail: OpenSSL berichtete: error:14090086:SSL
> routines:ssl3_get_server_certificate:certificate verify failed
> fetchmail: SSL-Verbindung fehlgeschlagen.
> fetchmail: Socket-Fehler beim Abholen von user3@pop.gmx.net
> fetchmail: Abfragestatus=2 (SOCKET)
> ...
>
> Hier die /etc/fetchmailrc
>
> set postmaster "postmaster"
> set nobouncemail
> set logfile /var/log/mail/fetchmail.log
> defaults
> bad-header accept
>
> poll pop.gmx.net with proto pop3
>       user 'user1@gmx.de' there with password 'pwuser1' is
> 'localuser1' here ssl
>      user 'user2@gmx.net' there with password 'pwuser2' is
> 'localuser2' here ssl
>       user 'user3@gmx.de' there with password 'psuser3' is
> 'localuser3' here ssl
>
> sslfingerprint "34:28:34:E3:72:21:BF:1C:B4:FA:28:C8:BD:C2:E3:23"
>       sslcertck
>       sslcertpath /etc/ssl/fetchmaild/certs/

Fingerprint habe ich nicht.Meine ist etwa

poll pop.gmx.net protocol POP3 user 000000 is ank@localhost pass dein_passwort no rewrite limit 200000 ssl

Entferne mal alles andere, was mit GMX zu tun hat aus deiner Datei, nehme
meine Zeile und passe die auf dich an.
-- 
Andreas
You know you are a redneck if
your dog doubles as your dishwasher.

[toc] | [prev] | [next] | [standalone]

#5603

FromMatthias Andree <matthias.andree@gmx.de>
Date2017-01-08 21:44 +0100
Message-ID<edfmlqFil3lU2@mid.dfncis.de>
In reply to#5600
Am 06.01.2017 um 23:03 schrieb Andreas Kohlbach:

> Entferne mal alles andere, was mit GMX zu tun hat aus deiner Datei, nehme
> meine Zeile und passe die auf dich an.

Bloß nicht, da fehlt "sslcertck" und damit der Schutz gegen Abhören.

[toc] | [prev] | [next] | [standalone]

#5602

FromMatthias Andree <matthias.andree@gmx.de>
Date2017-01-08 21:44 +0100
Message-ID<edfmkpFil3lU1@mid.dfncis.de>
In reply to#5599
Am 06.01.2017 um 21:13 schrieb Anton Blau:

> fetchmail: Fehler bei Server-Zertifikat-Überprüfung: self signed certificate in certificate chain
> fetchmail: Fehlendes Zertifikat als Vertrauensquelle: /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche Telekom Root CA 2
> fetchmail: Das kann bedeuten, dass das Wurzelzertifikat nicht unter den vertrauenswürdigen CA-Zertifikaten ist, oder dass c_rehash auf dem > Verzeichnis ausgeführt werden muss. Details sind in der > fetchmail-Handbuchseite im bei --sslcertpath beschrieben.
> fetchmail: OpenSSL berichtete: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed
> fetchmail: SSL-Verbindung fehlgeschlagen.
> fetchmail: Socket-Fehler beim Abholen von user3@pop.gmx.net
> fetchmail: Abfragestatus=2 (SOCKET)
...

> 
> poll pop.gmx.net with proto pop3
>       user 'user1@gmx.de' there with password 'pwuser1' is 'localuser1' here ssl
...
> sslfingerprint "34:28:34:E3:72:21:BF:1C:B4:FA:28:C8:BD:C2:E3:23"
>       sslcertck
>       sslcertpath /etc/ssl/fetchmaild/certs/

> Wie löse ich das?

Woher stammt das "sslcertpath"-Zeug? Wieso hat das so einen seltsamen Pfad?

Sind die Mozilla-Zertifikate der Zertifizierungsstellen, oder zumindest
das "Deutsche Telekom Root CA 2", dort hinterlegt, die Fehlermeldung
bemängelt ja deren Fehlen.

Ist c_rehash in der richtigen Version auf /etc/ssl/fetchmaild/certs/
ausgeführt?

[toc] | [prev] | [next] | [standalone]

#5607

FromAnton Blau <tony.blue@gmx.de>
Date2017-01-11 13:42 +0100
Message-ID<o5596q$1osf$1@adenine.netfront.net>
In reply to#5602
Am 08.01.2017 um 21:44 schrieb Matthias Andree:
> Am 06.01.2017 um 21:13 schrieb Anton Blau:
> Woher stammt das "sslcertpath"-Zeug? Wieso hat das so einen seltsamen Pfad?

Die Dateien habe ich gem. der Anleitung unter 
http://www.gtkdb.de/index_36_2328.html hier angelegt.

> Sind die Mozilla-Zertifikate der Zertifizierungsstellen, oder zumindest
> das "Deutsche Telekom Root CA 2", dort hinterlegt, die Fehlermeldung
> bemängelt ja deren Fehlen.

Im sslcertpath /etc/ssl/fetchmaild/certs/ war das "Deutsche Telekom Root 
CA 2" bisher nicht enthalten, jedoch unter /etc/ssl/certs:

/etc/ssl/certs# ls Deutsche_Telekom_Root_CA_2.pem  -la
lrwxrwxrwx 1 root root 65 Okt 20  2012 Deutsche_Telekom_Root_CA_2.pem -> 
/usr/share/ca-certificates/mozilla/Deutsche_Telekom_Root_CA_2.crt

Die Verzeichnisse unter /usr/share/ca-certificates/mozilla/ habe ich 
nicht selbst angelegt, das macht wohl ubuntu aus der Paketinstallation.

> Ist c_rehash in der richtigen Version auf /etc/ssl/fetchmaild/certs/
> ausgeführt?

c_rehash habe ich gerade nochmals auf der Ebene /etc/ssl laufen lassen:

Dort erhalte ich:

/etc/ssl# c_rehash
Doing /usr/lib/ssl/certs
WARNING: Skipping duplicate certificate ValiCert_Class_2_VA.pem.dpkg-new
WARNING: Skipping duplicate certificate ValiCert_Class_2_VA.pem.dpkg-new
WARNING: Skipping duplicate certificate AddTrust_External_Root.pem
WARNING: Skipping duplicate certificate AddTrust_External_Root.pem
WARNING: Skipping duplicate certificate UbuntuOne-Go_Daddy_Class_2_CA.pem
WARNING: Skipping duplicate certificate UbuntuOne-Go_Daddy_Class_2_CA.pem

Die doppelten Einträge wurden wohl vom System erstellt:

ls -la | grep ValiCert_Class_2_VA
lrwxrwxrwx 1 root root        33 Jan 11 13:35 55a10908.0 -> 
UbuntuOne-ValiCert_Class_2_VA.pem
lrwxrwxrwx 1 root root        33 Jan 11 13:35 bcdd5959.0 -> 
UbuntuOne-ValiCert_Class_2_VA.pem
-rw-r--r-- 1 root root      1066 Mai 29  2013 
UbuntuOne-ValiCert_Class_2_VA.pem
-rw-r--r-- 1 root root      1066 Jun 12  2012 
ValiCert_Class_2_VA.pem.dpkg-new

Kann ich die jeweils ältesten Dateien bedenkenlos löschen?

Vielen Dank!


Tony

[toc] | [prev] | [next] | [standalone]

#5608

FromMatthias Andree <matthias.andree@gmx.de>
Date2017-01-15 00:07 +0100
Message-ID<edvp98Fgp1dU1@mid.dfncis.de>
In reply to#5607
Am 11.01.2017 um 13:42 schrieb Anton Blau:
> Am 08.01.2017 um 21:44 schrieb Matthias Andree:
>> Am 06.01.2017 um 21:13 schrieb Anton Blau:
>> Woher stammt das "sslcertpath"-Zeug? Wieso hat das so einen seltsamen
>> Pfad?
> 
> Die Dateien habe ich gem. der Anleitung unter
> http://www.gtkdb.de/index_36_2328.html hier angelegt.

Ich habe den Kainzbauer Anfang 2014 (in dem Fall die für CentOS 6) schon
gebeten, diese fetchmail-Anleitungen mit dem Fingerprint-Geraffel
verschwinden zu lassen. Ist nicht passiert, immerhin steht bei Dir noch
sslcertck dabei, das knallt Dir zum Glück gerade auf die Füße -
Kainzbauers Anleitung zur Fingerprint-Beschaffung geht unsichere Wege,
prüft nichts, ist umständlich und überflüssig.

Hast Du in der fetchmail-manpage nachgelesen, was die dort
abgeschriebenen Optionen im einzelnen tun? Sieht nicht so aus.

>> Sind die Mozilla-Zertifikate der Zertifizierungsstellen, oder zumindest
>> das "Deutsche Telekom Root CA 2", dort hinterlegt, die Fehlermeldung
>> bemängelt ja deren Fehlen.
> 
> Im sslcertpath /etc/ssl/fetchmaild/certs/ war das "Deutsche Telekom Root
> CA 2" bisher nicht enthalten, jedoch unter /etc/ssl/certs:

Da guckt fetchmail in Deiner Konfiguration aber nicht mehr, weil Du den
Pfad angibst.

> /etc/ssl/certs# ls Deutsche_Telekom_Root_CA_2.pem  -la
> lrwxrwxrwx 1 root root 65 Okt 20  2012 Deutsche_Telekom_Root_CA_2.pem ->
> /usr/share/ca-certificates/mozilla/Deutsche_Telekom_Root_CA_2.crt

Danach habe ich nicht gefragt, sondern nach "dort [= in
/etc/ssl/fetchmaild/certs/]".

> /etc/ssl# c_rehash
> Doing /usr/lib/ssl/certs
> WARNING: Skipping duplicate certificate ValiCert_Class_2_VA.pem.dpkg-new

Hier ist die Konfiguration bei einem Paket- oder Systemupgrade nicht
aufgeräumt worden.  Diese .dpkg-new sollten vermutlich die Basisdatei
mal ersetzen...

> WARNING: Skipping duplicate certificate ValiCert_Class_2_VA.pem.dpkg-new
> WARNING: Skipping duplicate certificate AddTrust_External_Root.pem
> WARNING: Skipping duplicate certificate AddTrust_External_Root.pem
> WARNING: Skipping duplicate certificate UbuntuOne-Go_Daddy_Class_2_CA.pem
> WARNING: Skipping duplicate certificate UbuntuOne-Go_Daddy_Class_2_CA.pem
> 
> Die doppelten Einträge wurden wohl vom System erstellt:
> 
> ls -la | grep ValiCert_Class_2_VA
> lrwxrwxrwx 1 root root        33 Jan 11 13:35 55a10908.0 ->
> UbuntuOne-ValiCert_Class_2_VA.pem
> lrwxrwxrwx 1 root root        33 Jan 11 13:35 bcdd5959.0 ->
> UbuntuOne-ValiCert_Class_2_VA.pem
> -rw-r--r-- 1 root root      1066 Mai 29  2013
> UbuntuOne-ValiCert_Class_2_VA.pem
> -rw-r--r-- 1 root root      1066 Jun 12  2012
> ValiCert_Class_2_VA.pem.dpkg-new
> 
> Kann ich die jeweils ältesten Dateien bedenkenlos löschen?

Nein, Du musst schon schauen, was davon relevant ist, und ggf. für den
richtigen Dateinamen sorgen.

Du kannst dpkg-reconfigure ca-certificates und ggf.
update-ca-certificates verwenden.  Siehe die zugehörige Dokumentation.

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.mailserver

csiph-web