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

Groups > de.comm.software.mailserver > #7076

Re: [GMX] nicht erreichbar

Show key headers only | View raw

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

Back to de.comm.software.mailserver | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web