Nur von denen aus kannst das mailjet-relay nutzen.
Hm, ok. Danke.
Dann ist mailjet für mich nutzlos.
Bietet vielleicht Hetznor oder heinzundheinz ein Smarthost Relay für Serverkunden?
Weshalb fragt Netcup nicht einfach den SPF Record ab und lässt dann das Relaying zu?
Was habe ich verpasst? Oder war das bevor ich ZFS verwendet habe? (2021)
Hinweise lassen darauf schließen, dass der Fehler 2006 in/über OpenSolaris Einzug hielt (damals war ZFSonLinux, wie sich OpenZFS früher nannte, bei Version 0.6.5 angelangt), vgl. FreeBSD Bugzilla - Bug 275308: EN tracking issue for potential ZFS data corruption (comment #16).
warten auf openZFS 2.2.2, weil die aktuelle version, vermutlich beim block-clonen, daten verdünnt.
Es liegt nicht am block cloning, welches für ZFS 2.2.x nunmehr dennoch sicherheitshalber deaktiviert wurde; das Letztere macht das Auftreten des Problems lediglich wahrscheinlicher (insbesondere, weil u. a. die neuere Version von cp im Paket coreutils v9.2(?)ff diese Funktionalität verwendet). Die Problembeschreibung findet sich in diesem Heise-Diskussionsfaden (mit Verweis auf die ausführlichere Beschreibung "So you want to understand what's going on with all these reports of 'OpenZFS might be eating my data'").
FYI: Vor den neueren Versionen des Pakets coreutils habe ich im Übrigen inzwischen sowieso Respekt, da die Version 9.4 beim Neubau des Debian-/Ubuntu-Pakets in einer QEMU-Umgebung* für die riscv64-Architektur den Emulator zum Absturz brachte. Das ist bei der aktuellen Version 8.1.3 (mit inzwischen wirklich respektabler Unterstützung für diese Architektur) nicht ganz einfach zu bewerkstelligen … 
Sollen dann doch lieber erst einmal die Fedora-BetatesterNutzer ihren Spaß damit haben. 
* Kernel 5.15.x, ext4-Dateisystem
Und ein externer NS löst deine internen Adressen auf?
soweit ich den VeePay verstanden hab läuft auf einem externen RS sein AdGuard den er auf seinen clients als DNS eingetragen hat. und dass das bei internet ausfall ein suboptimales setup ist darauf wollte man ihn hinweisen.
Dazu hat doch jeder Router einen internen Cache..
setzt voraus dass der befragt wird und dass man weniger als TTL vorher eine abfrage gemacht hat.
Ziel ist es, ein USB C Kabel zum Nachttisch zu ziehen damit das Handy drahtlos laden kann.
a) Kabel und drahtlos sind irgendwie 2 nicht korrelierende Techniken würd ich mal sagen 
b) ich stell mein Phone in der Nacht auf Flugmodus und des liegt quasi am anderen Ende der Wohnung und sicher nicht neben dem Kopfpolster;
es sei denn in Schwaben stehen Nachttische neben dem Kühlschrank 
c) wie lange dauert es bis die Flosse auf die Art geladen wird?
wenn nicht deutlich länger als man schläft macht das überhaupt keinen Sinn;
m_ueberall wo lebst Du?
uname -a liefert Linux #$(hostname)# 6.6.3-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Nov 28 19:11:52 UTC 2023 x86_64 GNU/Linux
und das Packet ist in Version 9.3 
darauf wollte man ihn hinweisen.
Ah, ok. Dann war es einfach aus dem Zusammenhang gerissen...
dass man weniger als TTL vorher eine abfrage gemacht hat.
Für lokale Adressen ist der ja authoritativ...
m_ueberall wo lebst Du?
uname -a liefert Linux #$(hostname)# 6.6.3-200.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Nov 28 19:11:52 UTC 2023 x86_64 GNU/Linux
und das Packet ist in Version 9.3
Igitt, da läuft dafür ja noch ein URALT-QEMU v8.1.1 
Ich bevorzuge LTS-Versionen, was Kernel und (Basis-)Distribution anbelangt (deswegen ja auch Ubuntu 20.04, 22.04) und muss bis auf selektive Ausnahmen (wie viele das sind, sag' ich aber lieber nicht ) keinesfalls immer sofort "vornedran sein"; die Kombination von Kernel v5.15.x und zfs v2.1.14 funktioniert hier tadellos für arm64/amd64 (die erste Testumgebung bekommt erst in einigen Tagen eine neuere Kombination vorgesetzt), und an "Baustellen" auf Applikationsebene mangelt es eh nie, um die Zeit "totzuschlagen" ...
wie lange dauert es bis die Flosse auf die Art geladen wird?
Nicht viel länger als mit Kabel - und selbst wenn, in der Nacht ist es mir egal hauptsache es ist am Morgen voll.
Dazu hat doch jeder Router einen internen Cache...
Für lokale Adressen ist der ja authoritativ...
ein cache ist nicht authoritative.
Uiii. Das Internet zu fragen ob etwas sicher ist führt eigentlich immer nur zu feurigen Diskussionen an deren Ende der sichere Tod steht. Deshalb fang ich einfach mal mit der Menge an Elektrosmog an die du dadurch beim schlafen abbekommst. Achja, und die dich sicherlich töten wird! 🤪
(Und mit diesen Worten hol ich mir mal Popcorn und lege mich aufs Sofa…)
Die Menge ist es nicht. Die Frequenzen im CENELEC-A-Band, die die Smartmeter ins Haus abstrahlen, sind es, worüber man sich Sorgen machen müsste. Also nicht wundern, wenn man morgens müder ist, als abends beim Schlafengehen.
Soviel zum Popcorn.
Als Nicht-Elektriker kann ich dazu nur schreiben:
Elektroinstallationen in Möbeln sind sowieso ein ganz eigenes Thema. Auch und gerade solche, die nur mit Kabelbindern....
Weitergehen, hier gibt es nichts zu sehen.
Nein, das ist nicht der Druide, den Ihr sucht....
Und vergesst nicht: „Strom kann Euch lebensgefährlich umbringen.“
ein cache ist nicht authoritative.
Mann Mann Mann.
Es ist ein Caching Nameserver.
Und für die lokale Zone ist er sehr wohl Authoritativ.
Solche Haarspaltereien bin ich von hier garnicht gewohnt...
Und für die lokale Zone ist er sehr wohl Authoritativ.
wenn er das wäre würde es das problem der ausgefallenen lokalen namensauflösung wenns internet weg ist nicht geben. wir reden hier immernoch über das setup von VeePay , aber vielleicht verheimlicht er uns ja auch, dass er neben seinem remote AdGuard noch einen lokalen caching und für die lokale zone authoritativen DNS hat.
Solche Haarspaltereien bin ich von hier garnicht gewohnt...
müßig ist hier eher die schlampigkeit und das dauernde aus dem zusammenhang reissen.
Wichtige Information diesbezüglich: https://micronews.debian.org/2023/1702150551.html
Und mir ist gestern gar nicht aufgefallen, dass ich genau dieses Update am Laptop bereits um 19:00 installiert habe. Soeben fröhlich und nichtsahnend in diese Kernelversion gebootet 
Gleich mal die alte Version installiert, Paket sicherheitshalber entfernt, linux-image-amd64 downgegraded (snapshot.debian.org) und auf Hold gesetzt.
Ich habe ganz vergessen wie schnell die Angriffe losgehen wenn man einen VPS besitzt..
und das dauernde aus dem zusammenhang reissen.
Wir sind eben im Laberthread...
wenn er das wäre würde es das problem der ausgefallenen lokalen namensauflösung wenns internet weg ist nicht geben. wir reden hier immernoch über das setup von VeePay
gibt es auch nicht; weil der Rückschluß eines remoten AdGuard, dass es keinen lokalen Authoritativen/Caching DNS gäbe steht nirgends und steht auch nicht zur Diskussion;
es scheinen hier ein paar gewaltige Künstler TBT der Interpretationen zu sein;
und mit "kann nicht" im Sinne von "will nicht" sorgt man zusätzlich für schlechte Luft;
Ich habe ganz vergessen wie schnell die Angriffe losgehen
Ui, stimmt. Ich sollte die neuen Server mal runterfahren...
Ich habe ganz vergessen wie schnell die Angriffe losgehen wenn man einen VPS besitzt..
SSH? Den Standard-Port auf einen unüblichen Port ändern (zur Orientierung: https://nullsec.us/top-1-000-tcp-and-udp-ports-nmap-default/), und dann sieht das ganze wie folgt aus:
Oder noch besser: Einen SSH Jumphost nutzen. Die neuen 1€ VPS sind dafür ideal!
