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

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

Re: [GMX] nicht erreichbar

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [GMX] nicht erreichbar Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2024-08-11 10:17 +0200
    Re: [GMX] nicht erreichbar Tim Ritberg <tim@server.invalid> - 2024-08-11 10:24 +0200
    Re: [GMX] nicht erreichbar Jörg Lorenz <hugybear@gmx.net> - 2024-08-11 11:37 +0200
      Re: [GMX] nicht erreichbar Rolf Buenning <r.buenning@gmx.de> - 2024-08-11 15:35 +0000
        Re: [GMX] nicht erreichbar Jan Montag <vintage@thafaker.de> - 2024-08-18 20:15 +0200
          Re: [GMX] nicht erreichbar Matthias Andree <matthias.andree@gmx.de> - 2024-08-29 02:28 +0200
    Re: [GMX] nicht erreichbar Matthias Andree <matthias.andree@gmx.de> - 2024-08-12 22:42 +0200
      Re: [GMX] nicht erreichbar Sebastian Suchanek <sebastian.suchanek@gmx.de> - 2024-08-14 21:13 +0200
        Re: [GMX] nicht erreichbar Matthias Andree <matthias.andree@gmx.de> - 2024-08-18 15:00 +0200
          Re: [GMX] nicht erreichbar Thomas Hochstein <thh@thh.name> - 2024-08-21 23:53 +0200

#7070 — Re: [GMX] nicht erreichbar

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.

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
-- 
X-Post, FollowUp-To de.comm.software.mailserver

[toc] | [next] | [standalone]

#7071

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.
> 
> 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

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

#7072

On 11.08.24 10:17, Sebastian Suchanek wrote:
> 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.

-- 
"Alea iacta est." (Julius Caesar)

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

#7073

Jörg Lorenz <hugybear@gmx.net> schrieb:
> 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?
-- 
Gruß Rolf

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

#7077

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/

> Und womit holst du deine Mails ab, Schlaumeier?

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

#7086

Am 18.08.24 um 20:15 schrieb 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.

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

#7074

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.

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.

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

#7075

Thus spoke Matthias Andree:
> 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].

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

#7076

Am 14.08.24 um 21:13 schrieb Sebastian Suchanek:

>> 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.

Passt.

> 
>> 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.

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?

> 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).

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.

> 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.

> [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 ;-)

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

#7083

Matthias Andree schrieb:

> 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.

> 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

[toc] | [prev] | [standalone]

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

csiph-web