[GMX] nicht erreichbar

[Sebastian Suchanek]

[GMX (POP3) down]
- Ob andere User das gleiche Problem haben. (Anscheinend
ja.)
- Ob das Problem auf GMX-Seite oder auf User-Seite liegt.
(Anscheinend auf GMX-Seite.)
- Ob GMX evtl. irgendetwas "heimlich" umgestellt hat (z.B.
Server(-Adressen) umgezogen).
- Falls letzteres: welche Umstellungen man auf User-Seite
machen muss, damit alles wieder wie gewünscht funktioniert.

In einem Anfall von "Windowritis" habe ich gerade einfach 'mal
den fetchmail-Daemon neu gestartet - und siehe da: es
funktioniert wieder.

Allerdings verwundert mich das jetzt schon ziemlich. Ich hätte
eigentlich erwartet, dass fetchmail bei jedem Durchlauf (bei mir
alle 5min) neue Verbindungen zum Server aufbaut. D.h., wenn sich
'mal irgendwie, irgendwo etwas in der Verbindung verschluckt,
sollte sich das beim nächsten Durchlauf implizit automatisch
wieder geben.

Für die Diskussion über die Funktionsweise von Fetchmal leite
ich mal mit XP und f'up nach de.comm.software.mailserver um.


Tschüs,

Sebastian

[Tim Ritberg]

Post by Sebastian Suchanek

[GMX (POP3) down]
- Ob andere User das gleiche Problem haben. (Anscheinend
ja.)
- Ob das Problem auf GMX-Seite oder auf User-Seite liegt.
(Anscheinend auf GMX-Seite.)
- Ob GMX evtl. irgendetwas "heimlich" umgestellt hat (z.B.
Server(-Adressen) umgezogen).
- Falls letzteres: welche Umstellungen man auf User-Seite
machen muss, damit alles wieder wie gewünscht funktioniert.

In einem Anfall von "Windowritis" habe ich gerade einfach 'mal
den fetchmail-Daemon neu gestartet - und siehe da: es
funktioniert wieder.
Allerdings verwundert mich das jetzt schon ziemlich. Ich hätte
eigentlich erwartet, dass fetchmail bei jedem Durchlauf (bei mir
alle 5min) neue Verbindungen zum Server aufbaut. D.h., wenn sich
'mal irgendwie, irgendwo etwas in der Verbindung verschluckt,
sollte sich das beim nächsten Durchlauf implizit automatisch
wieder geben.
Für die Diskussion über die Funktionsweise von Fetchmal leite
ich mal mit XP und f'up nach de.comm.software.mailserver um.

Ich hatte gestern ein Zertifikats-Fehler im Thunderbird.

Tim

[Jörg Lorenz]

Post by Sebastian Suchanek
Allerdings verwundert mich das jetzt schon ziemlich. Ich hätte
eigentlich erwartet, dass fetchmail bei jedem Durchlauf (bei mir
alle 5min) neue Verbindungen zum Server aufbaut. D.h., wenn sich
'mal irgendwie, irgendwo etwas in der Verbindung verschluckt,
sollte sich das beim nächsten Durchlauf implizit automatisch
wieder geben.

Nicht raten: Testen.
Aber hier GMX durch den Cacao ziehen?
Ich sag's ja: *PEBKAC*. GMX hat hier nie einen Ausfall zu verzeichnen
gehabt.

Und fetchmail ist schlicht und ergreifend - wie figura beweist - nur
eine weitere Fehlerquelle, ohne grossen Nutzen zu stiften.

[Rolf Buenning]

Post by Jörg Lorenz
Ich sag's ja: *PEBKAC*. GMX hat hier nie einen Ausfall zu verzeichnen
gehabt.
Und fetchmail ist schlicht und ergreifend - wie figura beweist - nur
eine weitere Fehlerquelle, ohne grossen Nutzen zu stiften.

Und womit holst du deine Mails ab, Schlaumeier?

[Jan Montag]

Ich nutze dafür auf meinem kleinen Ubuntu Server "getmail" [^1], weil
Fetchmail zunehmen Probleme - auch und vor allem mit Google und deren
ständigen Neuerungen bezüglich Transportsicherheit - machte.
Mit Getmail hatte ich bisher noch nie Probleme beim Abholen der Mails
und bin zufrieden.

[^1] getmail ist ein MTA und stellt damit eine _einfache_ Alternative zu
fetchmail dar. Getmail ist in Python geschrieben.
https://pyropus.ca./software/getmail/

Post by Rolf Buenning
Und womit holst du deine Mails ab, Schlaumeier?

[Matthias Andree]

Post by Jan Montag
Ich nutze dafür auf meinem kleinen Ubuntu Server "getmail" [^1], weil
Fetchmail zunehmen Probleme - auch und vor allem mit Google und deren
ständigen Neuerungen bezüglich Transportsicherheit - machte.
Mit Getmail hatte ich bisher noch nie Probleme beim Abholen der Mails
und bin zufrieden.

Getmail prüft je nach Python-Version und der damit einbezogenen
Standardbibliothek die Zertifikate erst gar nicht... und das ist ein
Problem, weil in solchen Setups erst gar keine Transportsicherheit
besteht. Muss man nicht unbedingt Getmail vorwerfen, wenn die
zugrundeliegenede Bibliothek zu doof ist...

Das "zunehmend Probleme" bei fetchmail würde ich auch gerne technisch
untermauert haben, insbesondere mit Nachweis, dass das ein
fetchmail-Problem ist und nicht Problem des Anbieters oder einer völlig
vergammelten Distribution.

[Matthias Andree]

Post by Sebastian Suchanek

[GMX (POP3) down]
- Ob andere User das gleiche Problem haben. (Anscheinend
ja.)
- Ob das Problem auf GMX-Seite oder auf User-Seite liegt.
(Anscheinend auf GMX-Seite.)
- Ob GMX evtl. irgendetwas "heimlich" umgestellt hat (z.B.
Server(-Adressen) umgezogen).
- Falls letzteres: welche Umstellungen man auf User-Seite
machen muss, damit alles wieder wie gewünscht funktioniert.

In einem Anfall von "Windowritis" habe ich gerade einfach 'mal
den fetchmail-Daemon neu gestartet - und siehe da: es
funktioniert wieder.
Allerdings verwundert mich das jetzt schon ziemlich. Ich hätte
eigentlich erwartet, dass fetchmail bei jedem Durchlauf (bei mir
alle 5min) neue Verbindungen zum Server aufbaut. D.h., wenn sich
'mal irgendwie, irgendwo etwas in der Verbindung verschluckt,
sollte sich das beim nächsten Durchlauf implizit automatisch
wieder geben.

Moin Sebastian,

der Prozess lebt aber länger, wenn Du -d oder --daemon oder das
rcfile-Äquivalent verwendest, und möglicherweise cacht Dein Resolver
lokal auch Ergebnisse von DNS-Lookups über ein res_init() hinaus - was
auch nur für GNU glibc halbwegs dokumentiert ist. Um das halbwegs
einzuschätzen, braucht's mehr Info übers Betriebssystem,
Fetchmail-Version und Konfiguration. Welche libc mit welchem Resolver
und welcher Resolver-Konfiguration? Sieht von den Symptomen her so aus
als hätte Dein Resolver unterm Blech DNS-Adressen der GMX-Hosts
nachgehalten, und bei Störungen mag's sein, dass so'n großer Provider
auf Backup-Server umschalten kann, indem der einfach anderes DNS
ausspielt - wobei die dafür eigentlich "zu lange" TTL haben von
irgendwas jenseits 84000 s.

Wenn aber Dein Resolver jetzt die TTL verlängern würde oder aus einer
temporären Störung von irgendeiner "Suchhilfe" aka.
Werbeumleitungs-DNS-Würgerei Deines ISP falsche IP-Adressen für
*.gmx.net gecacht hätte... wäre einiges erklärt.

Wenn Du ausführliche fetchmail-Logs aus dem Störungszeitraum hast, schau
mal, ob die IP-Ranges sich nach dem fetchmail-Neustart geändert hätten.

Und setz den J.rg-Troll mal an die Sonne, wenn der hinter Deinem Haus im
Schatten lungert. Der hat Langeweile und muss in einen Zustand
verbracht werden, in dem der die besser aushält.

[Sebastian Suchanek]

Post by Matthias Andree

Post by Sebastian Suchanek

[GMX (POP3) down]
- Ob andere User das gleiche Problem haben. (Anscheinend
ja.)
- Ob das Problem auf GMX-Seite oder auf User-Seite liegt.
(Anscheinend auf GMX-Seite.)
- Ob GMX evtl. irgendetwas "heimlich" umgestellt hat
(z.B.
Server(-Adressen) umgezogen).
- Falls letzteres: welche Umstellungen man auf User-Seite
machen muss, damit alles wieder wie gewünscht
funktioniert.

In einem Anfall von "Windowritis" habe ich gerade einfach
'mal den fetchmail-Daemon neu gestartet - und siehe da: es
funktioniert wieder.
Allerdings verwundert mich das jetzt schon ziemlich. Ich
hätte eigentlich erwartet, dass fetchmail bei jedem
Durchlauf (bei mir alle 5min) neue Verbindungen zum Server
aufbaut. D.h., wenn sich 'mal irgendwie, irgendwo etwas in
der Verbindung verschluckt, sollte sich das beim nächsten
Durchlauf implizit automatisch wieder geben.

Erstmal Danke für ausführliche Antwort.

Post by Matthias Andree
der Prozess lebt aber länger, wenn Du -d oder --daemon oder
das rcfile-Äquivalent verwendest, und möglicherweise cacht
Dein Resolver lokal auch Ergebnisse von DNS-Lookups über
ein res_init() hinaus - was auch nur für GNU glibc halbwegs
dokumentiert ist.

Ich glaube nicht, dass es ein DNS-Problem war. Die Logfiles
sind inhaltlich ein bisschen spärlich, aber /var/log/mail.err
sagt(e) für die fragliche Zeit:

| [...]
| Aug 10 02:45:51 tigersclaw fetchmail[2298]: Authorization failure on *****@pop.gmx.net (previously authorized)
| [...]

("****" ist der anonymisierte Nutzername)
Das interpretiere ich so, dass fetchmail durchaus Verbindung
zum GMX-Server bekommen hat, dieser aber die Anmeldung
verweigert hat.

Post by Matthias Andree
Um das halbwegs einzuschätzen, braucht's
mehr Info übers Betriebssystem, Fetchmail-Version und
Konfiguration.

Das ist ein Debian Stretch[1], wobei fetchmail - abgesehen
natürlich von den hinterlegten externen Mailkonten - "out of
the box" läuft.

Post by Matthias Andree
Welche libc

| # dpkg -l | grep libc
| ii klibc-utils 2.0.4-9+deb9u1 amd64 small utilities built with klibc for early boot
| ii libc-bin 2.24-11+deb9u4 amd64 GNU C Library: Binaries
| ii libc-dev-bin 2.24-11+deb9u4 amd64 GNU C Library: Development binaries
| ii libc-l10n 2.24-11+deb9u4 all GNU C Library: localization files
| ii libc6:amd64 2.24-11+deb9u4 amd64 GNU C Library: Shared libraries
| ii libc6-dbg:amd64 2.24-11+deb9u4 amd64 GNU C Library: detached debugging symbols
| ii libc6-dev:amd64 2.24-11+deb9u4 amd64 GNU C Library: Development Libraries and Header Files
| [...]

Post by Matthias Andree
mit welchem Resolver und welcher Resolver-Konfiguration?

DNS macht ein auf der gleichen Kiste laufender bind9, der die
lokale Domain im LAN verwaltet und für alles Externe rekursiv
arbeitet.

Post by Matthias Andree
Sieht von den Symptomen
her so aus als hätte Dein Resolver unterm Blech
DNS-Adressen der GMX-Hosts nachgehalten, und bei Störungen
mag's sein, dass so'n großer Provider auf Backup-Server
umschalten kann, indem der einfach anderes DNS ausspielt -
wobei die dafür eigentlich "zu lange" TTL haben von
irgendwas jenseits 84000 s.

Wie's der Zufall will, hatte ich heute aufgrund von anderen
"Bauarbeiten" auch Fehlermeldungen von tatsächlich nicht
funktionierendem DNS. Das sieht in /var/log/mail.err so aus:

| [...]
| Aug 14 09:46:45 tigersclaw fetchmail[2331]: couldn't find canonical DNS name of pop.gmx.net (pop.gmx.net): Temporary failure in name resolution
| [...]

Also eine andere Fehlermeldung als am Sonntag (und auch eine,
wie ich sie bei einem DNS-Problem erwarten würde).

Post by Matthias Andree
Wenn aber Dein Resolver jetzt die TTL verlängern würde oder
aus einer temporären Störung von irgendeiner "Suchhilfe"
aka. Werbeumleitungs-DNS-Würgerei Deines ISP falsche
IP-Adressen für *.gmx.net gecacht hätte... wäre einiges
erklärt.

U.a. wegen solcher "Suchhilfen" mache ich einen großen Bogen
um die DNS-Server meines Providers. Besagter bind9 liefert
bei einer nicht vorhandenen Domain auch brav "NXDOMAIN"
zurück.

Post by Matthias Andree
Wenn Du ausführliche fetchmail-Logs aus dem
Störungszeitraum hast, schau mal, ob die IP-Ranges sich
nach dem fetchmail-Neustart geändert hätten.

Die fetchmail-Logs sind, wie gesagt, leider ziemlich spartanisch.
Ein erfolgreiches Abholen von Mails sieht da nur so aus:


| # grep fetchmail mail.log
| Aug 12 06:31:00 tigersclaw fetchmail[818]: 1 message for ***** at domain.tld (1166328 octets).
| Aug 12 06:31:01 tigersclaw fetchmail[818]: reading message *****@domain.tld:1 of 1 (1166328 octets) flushed
| [...]

(Auch hier wieder mit User- und Servernamen anonymisiert.)
D.h., die IP der abgefragten Server taucht hier aucht nicht
auf.

Post by Matthias Andree
Und setz den J.rg-Troll mal an die Sonne, wenn der hinter
Deinem Haus im Schatten lungert.
[...]

Ich hoffe doch stark, dass der *nicht* hinter meinem Haus
herumlungert. ;-)


Tschüs,

Sebastian

_____
[1] Ja, ich weiß, dass das alt ist. Das hat seine Gruende[tm].

[Matthias Andree]

Post by Sebastian Suchanek

Post by Matthias Andree
der Prozess lebt aber länger, wenn Du -d oder --daemon oder
das rcfile-Äquivalent verwendest, und möglicherweise cacht
Dein Resolver lokal auch Ergebnisse von DNS-Lookups über
ein res_init() hinaus - was auch nur für GNU glibc halbwegs
dokumentiert ist.

Ich glaube nicht, dass es ein DNS-Problem war. Die Logfiles
sind inhaltlich ein bisschen spärlich, aber /var/log/mail.err
| [...]
| [...]
("****" ist der anonymisierte Nutzername)
Das interpretiere ich so, dass fetchmail durchaus Verbindung
zum GMX-Server bekommen hat, dieser aber die Anmeldung
verweigert hat.

Passt.

Post by Sebastian Suchanek

Post by Matthias Andree
Um das halbwegs einzuschätzen, braucht's
mehr Info übers Betriebssystem, Fetchmail-Version und
Konfiguration.

Das ist ein Debian Stretch[1], wobei fetchmail - abgesehen
natürlich von den hinterlegten externen Mailkonten - "out of
the box" läuft.

Post by Matthias Andree
Welche libc

| # dpkg -l | grep libc
| ii klibc-utils 2.0.4-9+deb9u1 amd64 small utilities built with klibc for early boot
| ii libc-bin 2.24-11+deb9u4 amd64 GNU C Library: Binaries
| ii libc-dev-bin 2.24-11+deb9u4 amd64 GNU C Library: Development binaries
| ii libc-l10n 2.24-11+deb9u4 all GNU C Library: localization files
| ii libc6:amd64 2.24-11+deb9u4 amd64 GNU C Library: Shared libraries
| ii libc6-dbg:amd64 2.24-11+deb9u4 amd64 GNU C Library: detached debugging symbols
| ii libc6-dev:amd64 2.24-11+deb9u4 amd64 GNU C Library: Development Libraries and Header Files
| [...]

Post by Matthias Andree
mit welchem Resolver und welcher Resolver-Konfiguration?

DNS macht ein auf der gleichen Kiste laufender bind9, der die
lokale Domain im LAN verwaltet und für alles Externe rekursiv
arbeitet.

Hu, wenn old-old-stable schon "buster" ist... und mir
https://archive.debian.org/debian/dists/stretch/main/binary-amd64/
verrät, dass seinerzeit stretch mit 6.3.26 gekommen ist, kann ich nur
sagen, dass ich die meisten Bugs in dem alten Kram vergessen habe...

fetchmail 6.4.0 ist auch schon fast fünf Jahre alt.

Quatscht Dein System wenigstens TLS v1.2 mit der Außenwelt?

Post by Sebastian Suchanek
Wie's der Zufall will, hatte ich heute aufgrund von anderen
"Bauarbeiten" auch Fehlermeldungen von tatsächlich nicht
| [...]
| Aug 14 09:46:45 tigersclaw fetchmail[2331]: couldn't find canonical DNS name of pop.gmx.net (pop.gmx.net): Temporary failure in name resolution
| [...]
Also eine andere Fehlermeldung als am Sonntag (und auch eine,
wie ich sie bei einem DNS-Problem erwarten würde).

Okay, passt. Bleibt - was wir heute angesichts der Logs in fetchmail
6.uralt.x nicht mehr nachvollziehen können, weiterhin die Idee, dass GMX
- was innerhalb 24 h geht, wenn Du den Resolver nicht neustartest - ggf.
defekte Server per DNS rausrotiert hatte, und die "alten Server", die im
DNS letzten Sonntag nicht mehr sichtbar wären, irgendwo anders standen
oder Schluckauf mit Benutzerdatenbank oder was auch immer hatten.

Oder zufällig GMX das Problem in dem Moment gelöst hatte, als Du auch
sowieso den Service neu gestartet hattest.

Post by Sebastian Suchanek
Die fetchmail-Logs sind, wie gesagt, leider ziemlich spartanisch.

Mit -v oder set verbose werden sie recht ausführlich. Vermutlich mehr
als man im Dauerbetrieb will, aber die Serveradressen sollten dann
drinstehen.

Post by Sebastian Suchanek
[1] Ja, ich weiß, dass das alt ist. Das hat seine Gruende[tm].

Mag sein, aber wenn Du nicht ELTS bezahlst und auch OpenSSL- und
libc-Bugfixes bekommst, auch ein eher mutiges Unterfangen. Wenn der
Grund systemd wäre -> nimm FreeBSD ;-)

[Thomas Hochstein]

Post by Matthias Andree
Mag sein, aber wenn Du nicht ELTS bezahlst

ELTS ist kostenlos verfügbar. (Solange es überhaupt verfügbar ist, d.h.
Kunden - idR Firmen - dafür bezahlen.) Support gibt's aber halt nur für
die Pakete, für die irgendjemand zahlt.

Post by Matthias Andree
und auch OpenSSL- und libc-Bugfixes bekommst,

OpenSSL und glibc sind immer Teil von ELTS.
<https://www.freexian.com/lts/extended/docs/debian-9-support/>

-thh