Path: csiph.com!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Sebastian Suchanek Newsgroups: de.comm.software.mailserver Subject: Re: [GMX] nicht erreichbar Date: Wed, 14 Aug 2024 21:13:06 +0200 Lines: 136 Message-ID: References: <66B779D8.9030404@backwurst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8bit X-Trace: individual.net BuenVpRDKY917LAYG85SmQgiu21H7cZ8J0fs01Tmy4uHl95lk= Cancel-Lock: sha1:/5QADJ4ut0Y3xYZNW3ah0H+WvSo= sha256:2o2iX9Cgvv/favGtvxcy1htOp2LcVzdf5fzBfx/lXL0= User-Agent: Xnews/2005.10.18 Mime-proxy/1.4.c.1 (Win32) Hamster/2.1.0.11 X-Face: //SzobV}i|*=Ael([X.`2mqbxR)[{/\,EZ%&hMI`Hh:)K3g>hCB/hs\3(,v%=vu|Aug"0>Uql/*1KlD^BRTd@D2&3p~kY$/7^,{N{w Am 11.08.24 um 10:17 schrieb Sebastian Suchanek: >> Sebastian Suchanek macht die Ingrid: >> >>> [GMX (POP3) down] >>> Soweit es mich betrifft: >>> - 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. > 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. > 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. > 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 | [...] > 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. > 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). > 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. > 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. > 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].