Wohnzimmerhostblogger

Ein Kunde fragte heute bei uns nach seinen Zugangsdaten für unser Kundeninterface. Reflexartig schrieb ich ihm schon einmal in die Antwort-E-Mail, dass wir grundsätzlich alle Passwörter nur in verschlüsselter (genauer gehashter) Form vorhalten und keine Zugriff auf die Klartext-Passwörter haben, ich könnte ihm nur anbieten das Passwort zurückzusetzen - also neu zu vergeben.

Als ich vor dem Absenden der E-Mail aber noch fix durch die von ihm beigefügte Korrespondenz aus der Vergangenheit scrollte, war da doch tatsächlich noch eine automatische E-Mail von uns in der er ein neues Passwort erhalten hatte. Also Passwort getestet und als das doch tatsächlich funktionierte, die E-Mail kurz angepasst und dem Kunden das Passwort mit einem entsprechenden Verweis auf die Quelle zurückgesendet.

mail:~ # telnet xxx.xxx.xxx.xxx 25
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
220 xxxxx.xxxxxxx.xx ESMTP
EHLO mail.tiggerswelt.net
250-xxxxx.xxxxxxx.xx
250-STARTTLS
250-PIPELINING
250 8BITMIME
MAIL FROM:<support@tiggerswelt.net>
250 ok
RCPT TO:<xxx@xxxxx.xx>
250 ok
DATA
354 go ahead
Date: Mon,  9 Oct 2017 18:11:47 +0200 (CEST)
From: <support@tiggerswelt.net>
To: <xxx@xxxxxxx.xxx>
Subject: E-Mail-Zustellung funktioniert nicht

Hallo Xxxxx,

entschuldige bitte die Form dieser E-Mail, aber ich tippe das hier gerade
ueber telnet auf der Kommandozeile

Ich habe gerade eben die letzten zwei E-Mails an Dich (SEPA-Mandat + meine
Bestaetigung dazu) als nicht zustellbar zurueck bekommen. Grund hierfuer ist
dass die Domain xxxxxx.xx aktuell wohl ziemlich kaputt konfiguriert ist.    
Ich wuerde vermuten, dass hier schlichtweg der MX-Eintrag fehlt.

Ich schicke das hier daher mal an den Host, der Deine letzte E-Mail bei uns
eingeliefert hat...

Gruesse aus Stuttgart,

Bernd
.
250 ok 1507566571 qp 1906
QUIT
221 xxxxx.xxxxxxx.xx
Connection closed by foreign host.

... hat funktioniert! (Und ja, es fehlen die Pflichtangaben)

Nachdem mir kürzlich bei einem Kunden ein kommerzielles Wordpress-Plugin "aufgefallen" war (dazu noch dieses Jahr sicherlich irgendwann mehr), wollte ich den Hersteller dieses Plugins kontaktieren. Dieser verwies auf seiner Webseite mehrfach auf ein Support-Formular, das aber nur mittels Zugangsdaten erreichbar war und somit für mich als nicht-Kunden ausfiel.

Macht nichts, denn im Impressum gibt es ja eine E-Mail-Adresse!

Da sieht man bereits auf den ersten Blick, dass der Hersteller hier nicht gerne per E-Mail kontaktiert werden möchte, aber irgendwie gezwungen ist eine E-Mail-Adresse anzugeben. Aber es ging noch weiter: Auf der gesamten Seite und bei der E-Mail-Adresse im speziellen waren keine Textmarkierungen möglich und im HTML-Quelltext waren ein paar zusätzliche Hürden hinterlegt sodass selbst wenn Text markiert und kopiert werden kann am Ende immern och nur Müll dabei heraus kommt:

Grandios und Hut ab! Da hat sich jemand wahrlich Mühe gemacht.

Ich war so frei all diese Hürden zu umschiffen und an die E-Mail-Adresse (wie auch an die im WHOIS hinterlegte E-Mail-Adresse) mein Anliegen zu schicken. Bislang (erwartbar) ohne Antwort, sodass das sicherlich noch nicht das Ende der Geschichte ist....

In dieser Geschichte muss ich leider immer wieder berichten: Es war nicht das erste Mal, aber es ist nicht so schlimm gekommen wie es hätte sein können.

Am 13. März diesen Jahres kam eine Kundin auf uns zu und wollte gerne eine .com-Domain von einem Marktbegleiter zu uns zu transferieren um dort Wordpress zu installieren. Den Auth-Code zur Domain hatte sie bereits vorliegen - die Domain war ordentlich beim Anbieter zum Domain-Transfer gekündigt worden und dieser hatte die Daten auch entsprechend per E-Mail ausgehändigt. Soweit so gut.

Leider musste ich dann feststellen, dass die Domain noch gar nicht transferiert werden konnte, da sie noch den EPP-Status "clientTransferProhibited" hatte - in Stumpf: Der Anbieter hat die Domain noch nicht zum Transfer freigegeben, sodass sie (anders als z.B. eine .de-Domain) auch mit Auth-Code nicht transferiert werden kann. Da wir erst einmal keine Vertragspartei im bestehenden Hosting-Verhältnis waren bat ich den Kunden hier sich direkt an den Anbieter zu wenden und gab ihm noch ein paar Fachworte sowie eine Beschreibung des Problems mit, die er 1:1 in seine Korrespondenz übernehmen konnte. Zunächst passierte erst einmal zwei Wochen lang nichts, bis der Anbieter sich dann zurückmeldete und erneut den Auth-Code übermittelte - am EPP-Status der Domain änderte sich nichts.

Als es mir ein paar E-Mails später zu bunt wurde, versuchte ich mich in das Geschehen einzumischen - schließlich war mittlerweile April und für Ende Mai stand die Verlängerung der Domain an, was bei einem der Anbieter (wir oder die) zu Kosten führen würde, und ich war mir nur bei uns sicher, dass diese Verlängerung auch tatsächlich im Sinne des Kunden stattfinden würde (ich sollte Recht behalten). Auf den Umstand wies ich auch ebenfalls regelmäßig in meinen E-Mails hin, doch im Gegensatz zum "Glück" unseres Kunden sprach ich mit einer Wand. Niemand meldete sich zurück.

Der Kunde hatte mittlerweile seine ERRP-E-Mails und spottete eigentlich nur noch. Auf Antwort vom bisherigen Anbieter haben wir indes nicht mehr gehofft. Da ich in der Vergangenheit damit sehr gute Erfahrungen gemacht hatte, wendete ich mich in unserer Verzweiflung an den zuständigen Registrar und schilderte dort unser Problem - da ich den Inhaber und den Auth-Code hinter mir wusste war ich da eigentlich sehr zuversichtlich, da die nochmal einen anderen Support und ganz andere Möglichkeiten haben. Aber nein: Unser Anliegen wurde freundlich aber bestimmt zurückgewiesen - man verwalte Domains nur für seine Partner und wir sollten uns ausschließlich an eben jene Partner wenden. Das wir dies bereits ausführlich und mehrfach und mit mehr als angemessenen Fristen getan haben, lies man nicht gelten. (Seitdem fühle ich mich bestärkt in einer Entscheidung von 2011 diesen Anbieter doch nicht für den Einkauf auszuwählen. Bei unserem Partner hierfür wäre so etwas nicht passiert.)

Eine Woche später ergänzte die Domain des Kunden dann ihren EPP-Status um "pendingDelete". Der Name ist selbst-erklärend. Na wunderbar! Im April hatte ich bereits darauf hingewiesen, aber nicht in der Erwartung dass dies auch tatsächlich passieren würde. Also erneuerte ich hierzu die Informationen für den Kunden und wies ihn auf alle Optionen hin, die zu diesem Zeitpunkt bestehen. Wir alle resignierten.

Im Nachhinein vollkommen okay: Wir haben in der Vergangenheit schon des öfteren die Erfahrung gemacht, dass Anbieter Domains die eigentlich transferiert werden sollten willkürlich löschen - sei es aus Absicht, zu knappem Ende der Domain-Laufzeit oder aus Unfähigkeit - und unser Transfer-System entsprechend darauf vorbereitet. Als diese Woche die Domain final gelöscht wurde hat unser System dies erkannt und die Domain für unseren Kunden einfach neu registriert. Der Transfer ist damit "erfolgreich abgeschlossen": Unser Kunde ist (mit einer kurzen Unterbrechung) weiterhin Inhaber seiner Domain und die Domain liegt bei uns. Eigentlich alles super, aber es hätte auch anders laufen können da wir keine professionellen Domain-Grabber sind.

Ich frage mich, was an diesem Prozedere fair oder einfach gewesen sein soll - so wie der Anbieter sich selbst bewirbt. Im Prinzip nichts. Unser Kunde wollte nur einen Anbieterwechsel durchführen, schlussendlich hat er dabei viele Nerven und fast seine Domain verloren. Das ist nicht fair und auch nicht einfach, sondern einfach nur Mist. Und auch wenn mich solche großen Werbekampagnen immer etwas unruhig machen, so ist es am Ende doch immer nur Werbung und damit recht nahe an Fiktion. Ob das hier ein Einzellfall ist oder nicht ist mir egal.

Eigentlich sollte das hier schon im April kommen, aber irgendwie hat man immer mehr um die Ohren, als man gerne hätte:

Wir suchen Beta-Tester für unseren DDNS-Dienst mit Unterstützung für IPv4 und IPv6.

Nachdem wir gefühlt 10 Jahre lang unseren DDNS-Dienst nicht mehr angefasst haben zeichnet sich langsam aber stetig eine Änderung am Horizont ab: Er soll endlich fit für das Internet der Zukunft werden und IPv6 können, zumal die Anzahl der Kunden stetig steigt, die nativ von ihrem Provider nur IPv6 bekommen und IPv4 über ein CGN zu machen haben.

Im vergangenen Jahr haben wir hierzu unser DDNS-Frontend komplett neu entwickelt und für den Betrieb an Dual-Stack-Internetzugängen fit gemacht. Der Dienst ist dabei komplett abwärts-kompatibel mit der bisherigen DynDNS.org-Spezifikation (die es so vermutlich schon gar nicht mehr offiziell gibt), hat darüber hinaus aber noch ein paar Optionen z.B. für den Dual-Stack-Betrieb oder die Dienst-Antwort im JSON-Format von uns bekommen.

Endlich hält mal ein bisschen IPv6 Einzug bei uns. Bisher war das ein Thema, das eher so aussah als würden wir das verschlafen - obwohl hinter den Kulissen schon ganz ganz viel damit läuft und wir bereits seit einigen Jahren Erfahrungen damit sammeln. 2017 und 2018 wird es definitiv sehr viele neue Nachrichten rund um das Thema geben.

Wer hier mitliest und bei uns bereits eine Domain hat, die er gerne auch für IPv6 per DDNS updaten würde, kann sich gerne an den Support wenden. Die URL des Endpunktes verraten wir dort gerne samt ein wenig Einweisung.

Ich bin aktuell noch etwas unschlüssig, ob ich entsetzt oder recht amüsiert sein soll. Da ich ungern entsetzt bin und das vielleicht auch etwas übertrieben wäre, belasse ich es wohl beim amüsiert sein.

Hin und wieder (aber eigentlich ganz selten) brauche ich für ganz exotische Dinge ein Oszilloskop. Hierzu hatte ich vor kurzem ein Velleman WFS210 angeschafft - sicherlich kein Top-Modell, aber für meine Zwecke ausreichend und mit WLAN und TCP/IP für ganz andere Schandtaten spannend.

Heute bekam ich auf dem iPad allerdings einen Hinweis präsentiert, dass eine Verbindung mit dem Gerät nicht möglich sei und ich für iOS 10-Unterstützung eine neue Firmware auf dem WFS210 installieren sollte. "Schrecklich!" dachte ich mir. Ich würde nicht erwarten, dass ein iOS-Update eine Kommunikation auf dieser Ebene brechen könnte (außer vielleicht ein HTTPS-Zwang für App-Server-Kommunikation, aber dazu bin ich zu wenig in dieser Materie), aber das tat es offensichtlich und der Hersteller hat hierauf reagiert. Soweit so gut.

Bei Hardware mit Netzwerk-Anbindung bin ich nun irgendwie gewohnt, dass man Updates auch über eben diese Schnittstelle einspielen kann - daher dann auch mein Entsetzen: Denn anders als erwartet, lässt sich bei dem WFS210 die Firmware eben nicht über Software einspielen. Stattdessen muss das Gehäuse geöffnet und der Chip neu geflasht werden. Wohl dem, der entsprechendes Equipment im Schrank liegen hat.

Kaum jemand hat es bemerkt, aber ich war kurz weg und bin nun wieder da und lebe noch.

Das ist schon ein wenig der Rede wert, denn ich war ja schon einmal weg...

Ich habe in der Tat erst gestern zum ersten Mal von HTTPOXY gelesen - beim CERT.at. Seitdem Hanno Böck heute auf Golem.de darüber berichtet hat verbreitet sich die Nachricht sicherlich etwas schneller. Ein wenig unangenehm ist es mir irgendwie schon, denn im Prinzip ist das mögliche Problem hierbei bereits seit 2001 bekannt. Doch was genau soll hier überhaupt das Problem sein und ist es wirklich eines?

Wird eine HTTP-Anfrage über CGI oder FastCGI an einen anderen Prozess, z.B. einen PHP-Interpreter, zur Bearbeitung weitergegeben, so werden die HTTP-Header als Umgebungsvariable registriert. Jeweils mit einem HTTP_-Prefix und dem Namen aus dem HTTP-Header in Großbuchstaben, Bindestriche werden dabei zu Unterstrichen. Ruft dieser Prozess nun einen anderen Prozess auf oder arbeitet mit einer Bibliothek bzw. einem Framework die auf spezielle Umgebungsvariablen zugreifen, so lassen sich hier eventuell über eine HTTP-Anfrage ungewünschte Werte injezieren - so erinnert es in abgemilderter Form an die register_globals von PHP, die vor Jahren per default aktiviert waren und für jede Menge Kopfschmerzen gesorgt haben.

Problematisch wird es bei HTTPOXY, wenn die besagte Software mittels einer weiteren HTTP-Anfrage auf einen externen Dienst zugreifen soll und hierzu die Umgebungsvariable HTTP_PROXY bei der Auswahl eines eventuell vorgeschalteten Proxy zu Rate zieht. In diesem Fall könnte ein Angreifer von außen alle HTTP-Anfragen über einen eigenen Server umleiten und Einsicht in den Datenverkehr nehmen solange dieser nicht verschlüsselt ist. Je nach Gründlichkeit der Entwickler ist auch denkbar einen Man-In-the-Middle-Angriff auf HTTPS-Verbindungen zu nehmen - hierbei gelten natürlich die üblichen MITM-Hürden: Die ursprüngliche Anwendung dürfte das SSL-Zertifikat nicht validieren oder müsste eine falsche Domain dort stillschweigend akzeptieren, damit dieser Angriff auch für HTTPS funktioniert.

Bei uns im Hosting kann ich natürlich nicht für die Skripte unserer Kunden sprechen, aber ich habe zur Sicherheit bereits gestern mal einen Blick auf die Software-Umgebung geworfen, wie wir sie jedem Kunden bereitstellen. Grundsätzlich bin ich hier beruhigt: Es fanden sich 3-4 Hinweise in einigen vorinstallierten PEAR-Bibliotheken von PHP sowie in der von uns verwendeten libXML2. Bei libXML2 wollte ich noch nachschauen, ob dies überhaupt ein Problem sein könnte - z.B. wenn ein XML/HTML-Dokument von extern geladen wird - aber das steht noch auf meiner ToDo und spielt auch eigentlich schon keine Rolle mehr...

... denn selbstredend sind wir den Vorschlägen gefolgt und haben eine Handvoll Proxy-Header in HTTP-Anfragen gesperrt. Dabei sind wir den Empfehlungen der CERT.at gefolgt und haben nicht nur den Proxy-Header sondern noch ein paar weitere Varianten gesperrt. Ich habe überlegt, ob es legitim ist einfach so und pauschal Header-Einträge aus dem Verkehr zu nehmen, allerdings ist kein Proxy-Header bei der IANA registriert und nicht-Standard-Header sollten entsprechend einen "X-"-Prefix tragen (Ich bin ein alter, alter Mann).

Irgendwie fühlt es sich komisch an, wenn ein Kunde vier Pakete mit Hardware von uns erhält und eines davon nach dem Einlieferungszentrum über eine komplett andere Route zum Empfänger geht als die drei anderen Geschwister.

Na hoffentlich geht da alles gut. Ich behalte das im Auge, UPS!

Seit heute gibt es bei uns die Möglichkeit einmal PHP 7 im Webhosting auszuprobieren.

Ich hatte es mehr zum Spaß mal in unser Build-System integriert und es lief auf Anhieb ohne Probleme. Einzig die meisten PECL-Extensions die wir immer dazu bauen, wollten nicht kompilieren. Genau genommen war "proctitle" die einzige Extension die ohne murren durchlief, alles andere brach mit Fehlern ab. Ich habe mir nicht die Mühe gemacht zu schauen, was da schief lief. Solange PHP 7 noch Beta ist, habe ich da ernsthaft keine Zeit für.

Parallel zu diesem Experiment habe ich die Versions-Verwaltung für PHP etwas verbessert. So pflegen wir nun auch Pseudo-Versionen wie "PHP 5" oder "PHP 5.6", die immer der höchsten für diesen Zweig verfügbaren PHP-Version entsprechen. In beiden Beispielen wäre das heute also PHP 5.6.11. Umschalten lässt sich die PHP-Version ganz einfach indem man bei uns in der php.ini eine Direktive

[php]
version = 5.6

platziert. Dabei sollte dann aber auch der include_path und etwaige Pfade zu Zend-Extensions (wie "opcache") angepasst werden.

Ich habe ja kürzlich festgestellt, dass ich doch noch irgendwie gelesen werde. Daher einfach mal die Frage:

Gibt es unter meiner Leserschaft Autoren mit Wordpress-Blog, die regelmäßig Artikel im Bereich um die 1.800 Zeichen schreiben und darauf an die 1.500 Zugriffe pro Jahr verzeichnen?

Die Betroffenen wissen hoffentlich worum es mir geht und ich würde genau hier noch ein paar Beta-Tester suchen, denen ich 2-3 Abende an Arbeit abnehmen kann.

Gestern in der Mail eines Kunden gelesen und herzlich geschmunzelt:

PS> Ich habe deinen Blog noch im Feedreader - den DNSSEC post fand ich auch interessant und amüsant, nur falls du dich fragst ob das noch wer liest

Ja, ich frage mich in der Tat oft, ob das hier noch jemand liest und wünschte mir oft, dass ich mehr Zeit und Inhalt für den Blog hätte. Nach wie vor passiert hier wahnsinnig viel, aber die alte Leichtigkeit einfach "unterwegs" mal darüber zu bloggen ist irgendwie weg. Heute ist es dann meist ein "Da schreibst Du drüber, wenn Du damit fertig bist".

Ich musste drei oder vier Mal gucken und habe es im ersten Moment nicht wirklich glauben wollen:
Das "DNS Root Key Signing Certificate" der IANA (Internet Assigned Numbers Authority) enthält einen formalen Fehler (hier verlinkt). Ausgestellt wurde das Zertifikat von der ICANN, die kommissarisch die Aufgaben der IANA wahrnimmt.

Wo ich zunächst einen Fehler in unserer Software vermutet habe, die wir zum Verarbeiten von ASN.1-Objekten einsetzen (dazu zählen eben auch X.509 Zertifikate) und mich dort auf die Suche nach einem Fehler gemacht habe, musste ich schlussendlich herausfinden, dass die Software hervorragend arbeitet und höchstens etwas streng validiert - ASN.1 hat keinen sonderlich guten Ruf und der Hauptkritikpunkt hier liegt wohl in der etwas verkopften bzw. zu abstrakten, manchmal schwer zu implementierenden Definition dieser binären Beschreibungssprache und so hätte ich mich erst einmal nicht gewundert, sollte bei uns etwas schief gelaufen sein.

Mit der Zeit konnte ich aber ziemlich genau herausfinden, an welcher Stelle im Zertifikat der IANA der "Fehler" liegt - ich gehe an dieser Stelle bewusst dazu über den "Fehler" in Anführungszeichen zu setzen, da er im Prinzip nur formaler Natur ist und eigentlich zu keinen praktischen Problemen (z.B. bei der Signierung von DNSSEC-Daten und der Validierung solcher Unterschriften) kommen sollte. Allerdings finde ich es bezeichnend, dass so ein Fehler bei der IANA bzw. ICANN auftritt. Immerhin sind diese beiden Organisationen zwei wesentliche Organe der Verwaltung des Internets. Aber was ist eigentlich mein das Problem?

Das Problem ist, dass das oben angesprochene Zertifikat von der folgenden Stelle unterschrieben wurde:

Organisation: ICANN
Allgemeiner Name: ICANN DNSSEC CA
E-Mail-Adresse: dnssec@icann.org

Das an sich stellt natürlich kein Problem dar. Jeder im Internet darf eine eigene Certificate Authority (CA) erstellen und damit andere Zertifikate ausstellen bzw. unterschreiben - auch die ICANN darf das, vielleicht sogar gerade die ICANN. Der "Name" der unterschreibenden Organisation ist in X.509-Zertifikaten recht aufwendig kodiert. Im Prinzip ist das eine Aneinanderreihung von Bezeichnungen bzw. sog. Attributen. Jedes Attribut hat hierbei eine Kennung ("Object ID") und einen damit verwandten Wert, die meistens als "Printable String", "IA5 String" oder "UTF-8 String" kodiert werden. In der Praxis ist das sicherlich etwas komplexer und primär dem oben genannten ASN.1 geschuldet, ich belasse es aber bei dieser einfachen Darstellung.

Das IANA-Zertifikat verwendet an dieser Stelle ausschließlich "Printable Strings" und genau hier liegt ein ganz banales Problem: Ein "Printable String" kennt kein "@"- oder "&"-Zeichen, der oben genannte Aussteller des Zertifikates hat jedoch seine E-Mail-Adresse vermerkt - und die kommt bekanntlich nicht ohne "@"-Zeichen aus.

Selbstverständlich habe ich meine Annahme mit OpenSSL verifiziert ("openssl asn1parse -inform pem < Kjqmt7v.crt"):

[...]
75:d=3  hl=2 l=  31 cons: SET
77:d=4  hl=2 l=  29 cons: SEQUENCE
79:d=5  hl=2 l=   9 prim: OBJECT            :emailAddress
90:d=5  hl=2 l=  16 prim: PRINTABLESTRING   :dnssec@icann.org
[...]

Bemerkenswert ist an dieser Stelle (wie auch im x509-Modul von OpenSSL), dass OpenSSL die Kodierung nicht als Fehlerhaft wertet oder einen entsprechenden Fehler ausgibt. Aber schon die Wikipedia sieht das anders: Dort wird schon unter der Tabelle der erlaubten Zeichen darauf hingewiesen, dass das "@"-Zeichen im Subset des "Printable String" nicht enthalten ist und dies ein typischer Fehler für einen "naiven Implementierer" ist. Formal definiert ist der "Printable String" in X.680, Kapitel 41, Absatz 4 (Seite 88) - wo sich die Tabelle der Wikipedia auch noch einmal verifizieren lässt.

Es liegt mir fern die IANA oder ICANN als "naiv" zu bezeichnen (auch wenn der Absatz über die Wikipedia dies nahe legen könnte), aber es drängt sich irgendwie die Frage auf, wie die dort ihre Zertifikate erstellen, dass sich so ein "Fehler" einschleichen kann.

Auf meine Arbeit an sich hatte das übrigens keinen Einfluss - ich war ohnehin nur am "Subject Public Key"-Teil des Zertifikates interessiert und der war intakt.

Wenn Du morgens früh um 7 Uhr Deinen Laptop im Server-Rack einschließt und erst kurz vor dem Ausgang merkst, dass Dir etwas fehlt, war die Nacht vermutlich ein bisschen zu kurz.

Hin und wieder kommt es mal vor, dass am Sonntag Abend eine E-Mail hier eintrudelt, in der gleich zu Beginn ein angenehmer Montag morgen gewünscht wird.

Mir ist aufgefallen, dass das eigentlich in 99% der Fälle zu einem "Challenge accepted" führt und die E-Mail trotz des Sonntags und vielleicht auch der schon fortgeschrittenen Stunde sofort beantwortet wird. Manchmal dann auch mit einem etwas frechen Hinweis, dass es doch noch zu früh sei als das man von "Montag morgen" sprechen könnte

Auf diesem Wege an die Autoren solcher Mails ein "Well done!", das scheint ein sehr effektiver Weg zu sein, wie man auch am Wochenende auf freundliche Art und Weise noch seine Anfragen beantwortet bekommt (was nicht heißt, dass am Wochenende ausschließlich solche E-Mails beantwortet werden und andere nicht).