Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
fetchmail + gmx -> ein Postfach funktioniert nicht
216 views
Skip to first unread message
Tony Blue
May 10, 2014, 10:34:05 PM5/10/14
to
Hallo Newsgroup,
ich hole per fetchmail mehrere Postfï¿œcher bei gmx ab. User1 + User2
funktionieren. Leider werden die Mails fï¿œr user3 nicht abgeholt.
/etc/fetchmailrc
set postmaster "postmaster"
set nobouncemail
set logfile /var/log/mail/fetchmail.log
poll pop.gmx.net with proto POP3
user 'us...@gmx.de' there with password 'password1' is
'localuser1' here ssl
user 'us...@gmx.net' there with password 'password2' is 'user2'
here ssl
user 'us...@gmx.net' there with password 'password3' is 'user3'
here ssl
sslfingerprint "XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX"
sslcertck
sslcertpath /etc/ssl/fetchmail/certs/
Beim Abholen der E-Mails erhalte ich folgende Fehlermeldung:
fetchmail: 6.3.21 fragt pop.gmx.net ab (Protokoll POP3) um So 11 Mai
2014 04:25:41 CEST: Abfrage gestartet
Versuche, mit 212.227.17.169/995 zu verbinden...verbunden.
fetchmail: Zertifizierungskette, von der Wurzel zum Server, ab Tiefe 2:
fetchmail: Herausgeber-Organisation: Deutsche Telekom AG
fetchmail: Herausgeber-CommonName: Deutsche Telekom Root CA 2
fetchmail: Subjekt-CommonName: Deutsche Telekom Root CA 2
fetchmail: Fehler bei Server-Zertifikat-ï¿œberprï¿œfung: self signed
certificate in certificate chain
fetchmail: Das heiï¿œt, dass das Wurzelzertifikat (ausgestellt fï¿œr
/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche
Telekom Root CA 2) 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.
141432186782400:error:15097686:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed:s3_clnt.c:1166:
fetchmail: SSL-Verbindung fehlgeschlagen.
fetchmail: Socket-Fehler beim Abholen von us...@gmx.net@pop.gmx.net
Wie bekomme ich das in den Grff?
Vielen Dank!
Tony
ich hole per fetchmail mehrere Postfï¿œcher bei gmx ab. User1 + User2
funktionieren. Leider werden die Mails fï¿œr user3 nicht abgeholt.
/etc/fetchmailrc
set postmaster "postmaster"
set nobouncemail
set logfile /var/log/mail/fetchmail.log
poll pop.gmx.net with proto POP3
user 'us...@gmx.de' there with password 'password1' is
'localuser1' here ssl
user 'us...@gmx.net' there with password 'password2' is 'user2'
here ssl
user 'us...@gmx.net' there with password 'password3' is 'user3'
here ssl
sslfingerprint "XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX"
sslcertck
sslcertpath /etc/ssl/fetchmail/certs/
Beim Abholen der E-Mails erhalte ich folgende Fehlermeldung:
fetchmail: 6.3.21 fragt pop.gmx.net ab (Protokoll POP3) um So 11 Mai
2014 04:25:41 CEST: Abfrage gestartet
Versuche, mit 212.227.17.169/995 zu verbinden...verbunden.
fetchmail: Zertifizierungskette, von der Wurzel zum Server, ab Tiefe 2:
fetchmail: Herausgeber-Organisation: Deutsche Telekom AG
fetchmail: Herausgeber-CommonName: Deutsche Telekom Root CA 2
fetchmail: Subjekt-CommonName: Deutsche Telekom Root CA 2
fetchmail: Fehler bei Server-Zertifikat-ï¿œberprï¿œfung: self signed
certificate in certificate chain
fetchmail: Das heiï¿œt, dass das Wurzelzertifikat (ausgestellt fï¿œr
/C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche
Telekom Root CA 2) 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.
141432186782400:error:15097686:SSL
routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
failed:s3_clnt.c:1166:
fetchmail: SSL-Verbindung fehlgeschlagen.
fetchmail: Socket-Fehler beim Abholen von us...@gmx.net@pop.gmx.net
Wie bekomme ich das in den Grff?
Vielen Dank!
Tony
Juergen Ilse
May 11, 2014, 12:53:02 AM5/11/14
to
Hallo,
Tony Blue <tony...@gmx.de> wrote:
> Beim Abholen der E-Mails erhalte ich folgende Fehlermeldung:
>
> fetchmail: 6.3.21 fragt pop.gmx.net ab (Protokoll POP3) um So 11 Mai
> 2014 04:25:41 CEST: Abfrage gestartet
> Versuche, mit 212.227.17.169/995 zu verbinden...verbunden.
> fetchmail: Zertifizierungskette, von der Wurzel zum Server, ab Tiefe 2:
> fetchmail: Herausgeber-Organisation: Deutsche Telekom AG
> fetchmail: Herausgeber-CommonName: Deutsche Telekom Root CA 2
> fetchmail: Subjekt-CommonName: Deutsche Telekom Root CA 2
> fetchmail: Fehler bei Server-Zertifikat-Überprüfung: self signed
> certificate in certificate chain
> fetchmail: Das heißt, dass das Wurzelzertifikat (ausgestellt für
> ist, oder dass c_rehash auf dem Verzeichnis ausgeführt werden muss.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Tony Blue <tony...@gmx.de> wrote:
> Beim Abholen der E-Mails erhalte ich folgende Fehlermeldung:
>
> fetchmail: 6.3.21 fragt pop.gmx.net ab (Protokoll POP3) um So 11 Mai
> 2014 04:25:41 CEST: Abfrage gestartet
> Versuche, mit 212.227.17.169/995 zu verbinden...verbunden.
> fetchmail: Zertifizierungskette, von der Wurzel zum Server, ab Tiefe 2:
> fetchmail: Herausgeber-Organisation: Deutsche Telekom AG
> fetchmail: Herausgeber-CommonName: Deutsche Telekom Root CA 2
> fetchmail: Subjekt-CommonName: Deutsche Telekom Root CA 2
> certificate in certificate chain
> fetchmail: Das heißt, dass das Wurzelzertifikat (ausgestellt für
> /C=DE/O=Deutsche Telekom AG/OU=T-TeleSec Trust Center/CN=Deutsche
> Telekom Root CA 2) 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.
> 141432186782400:error:15097686:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed:s3_clnt.c:1166:
> fetchmail: SSL-Verbindung fehlgeschlagen.
> fetchmail: Socket-Fehler beim Abholen von us...@gmx.net@pop.gmx.net
> Wie bekomme ich das in den Grff?
Verzichte bei diesem Server auf den Certificate-Check.
> beschrieben.
> 141432186782400:error:15097686:SSL
> routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify
> failed:s3_clnt.c:1166:
> fetchmail: SSL-Verbindung fehlgeschlagen.
> fetchmail: Socket-Fehler beim Abholen von us...@gmx.net@pop.gmx.net
> Wie bekomme ich das in den Grff?
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.
Tony Blue
May 11, 2014, 3:21:43 AM5/11/14
to
Am 11.05.2014 06:53, schrieb Juergen Ilse:
>
> Verzichte bei diesem Server auf den Certificate-Check.
Damit meinst Du die Option
>
> Verzichte bei diesem Server auf den Certificate-Check.
sslcertck
in der fetchmailrc raus - oder?
Vielen Dank!
Tony
Tony Blue
May 11, 2014, 11:20:42 AM5/11/14
to
Am 11.05.2014 09:21, schrieb Tony Blue:
> Am 11.05.2014 06:53, schrieb Juergen Ilse:
Das Ändern der /etc/fetchmailrc in
> Am 11.05.2014 06:53, schrieb Juergen Ilse:
...
# sslcertck
sslproto ssl23
...
hat das Problem behoben.
Vielen Dank!
Tony
Message has been deleted
Matthias Andree
May 12, 2014, 3:39:07 PM5/12/14
to
2. Telekom Root CA 2 Zertifikat installieren, z. B. durch Installation
der ca-root-certificates oder ï¿œhnlicher Pakete der Distribution, ggf.
manuell
3. verstehen, dass sich User-Optionen wie sslcertck nur auf das
unmittelbar voranstehende "user... pass..." beziehen - wie in der
Manpage beschrieben.
Es empfiehlt sich deswegen, die per "defaults"-Statement zu setzen, z.
B. vorweg sowas einzutragen:
defaults
bad-header accept
keep
sslcertck
Anderenfalls werden nï¿œmlich die Zertifikate fï¿œr user1 und user2 nicht
ï¿œberprï¿œft - das ist nicht im Sinne des Erfinders und vermutlich eine
unbeabsichtigte Fehlkonfiguration.
HTH
0 new messages