Technik

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)

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.

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

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

Auf heise.de wurde heute der Heartbleed-Check von lastpass.com referenziert.Die Software ist aber absoluter Müll und sollte nicht für eine qualifizierte Aussage darüber, ob ein Server für Heartbleed anfällig ist oder nicht herangezogen werden.

Nach allem Anschein, scheint die Software nur zu prüfen, welche Server-Software (HTTP-Header "Server") verwendet wird und ob diese eventuell OpenSSL verwendet. Zusätzlich wird noch geprüft, wann das Zertifikat ausgestellt wurde und ob dieser Zeitpunkt vor vergangenem Dienstag (dem 8.4.2014) liegt.

So etwas als Heartbleed-Test zu verkaufen ist falsch und grob fahrlässig. Zu raten, ob eine Software die sich im HTTP-Header als "Apache" ausgibt folglich auch OpenSSL verwendet ist schon falsch. Es ist mit Apache auch möglich GnuTLS zu verwenden. Statistisch gesehen tut das niemand, aber möglich ist es. Zudem ist es notwendig zu prüfen, ob die Heartbeat-Extension überhaupt im TLS-Handshake angeboten wird bzw. praktisch genutzt werden kann - nichts von beidem geschieht hier. Ich habe sowohl Server getestet, die OpenSSL 0.9.8 verwenden (und Heartbeat gar nicht können), die OpenSSL 1.0.1 ohne Heartbeat (-DOPENSSL_NO_HEARTBEATS) verwenden und solche, die mit der aktuellsten nicht anfälligen OpenSSL-Version laufen. Alle werden als gefährlich eingestuft.

Weiter ist auch das Gültigkeitsdatum im Zertifikat kein Hinweis darauf, dass das Zertifikat vor dem 8.4.2014 ausgestellt wurde. Wird ein Zertifikat wegen Kompromittierung des Schlüssels ausgetauscht, erhält man unter Umständen das selbe Zertifikat nur für einen anderen privaten Schlüssel. Das Zertifikat ist daher nicht mehr anfällig. Legitim wäre der Test, wenn man in der CRL des Ausstellers nachsieht, ob das Zertifikat zwischenzeitlich widerrufen wurde - das wird aber wenig praktikabel sein.

Leider hat auch heise.de in diesem Fall mächtig daneben gegriffen, nachdem mich schon die Bild-ähnlichen Überschriften zu diesem Thema aufgeregt haben, haben sie es nun auch inhaltlich unterstrichen.Zu LastPass sei gesagt, dass sie es bestimmt gut gemeint, aber eben schlecht gemacht haben. Immerhin funktioniert der Test in diese eine Richtung falsch: Lieber einmal zuviel falsch warnen als einmal zuviel entwarnen.

Auch wenn die Fragen hierzu bisher nicht so oft kamen, wie ich mir das erhofft hätte, mag ich mal ein wenig erzählen, wie wir in den letzten 2,5 Tagen den Heartbleed-Bug von OpenSSL erlebt haben:

Als am 7.4. gegen 19:30 das OpenSSL-Update kam, klang alles noch recht harmlos. Erst das Security Advisory eine Stunde später verdeutlichte dass da etwas im Argen lag. Wir haben dementsprechend gleich für den nächsten Morgen ein Dringlichkeits-Update angesetzt. Ich war auch versucht, das ganze noch am selben Abend durchzuziehen, aber irgendwie war mir das zu heikel, OpenSSL ist immerhin ein zentraler Bestandteil der Webserver-Software.

Am nächsten Morgen gab es dann recht schnell ein Software-Updates, einen Test im "Trockendock" und dann das Rollout auf sämtliche Server, die OpenSSL 1.0.1 nutzen - das ist mittlerweile der Großteil aller Server. Irgendwie war mir Angst und Bange, aber es ging alles gut. Und auch alle folgenden Tests waren erfolgreich.

In der Zwischenzeit haben wir mit unserem Partner für SSL-Zertifikate geklärt, wie wir am einfachsten die diversen über uns verkauften bzw. auch bei uns eingesetzten SSL-Zertifikate möglichst einfach tauschen und die alten Zertifikate widerrufen können. Die Situation ist insofern neu für uns, als das vielleicht schon mal ein private Schlüssel abhanden gekommen ist (nicht bei uns) und ein einzelnes Zertifikat getauscht werden musste. So viele potentielle Tauschvorgänge auf einmal ist hingegen komplett neu für uns.

Ich habe heute dann alle Kunden, die ein SSL-Zertifikat über uns eingekauft haben, wie auch alle Kunden, die SSL-Zertifikate bei uns hochgeladen haben (um sie auf dem Webserver zu nutzen), per Mailing informiert. Zum einen ist es wichtig zu wissen, dass auch wir Webserver im Einsatz hatten, die für diesen Fehler anfällig waren, und die Bedrohung nun erst einmal vorüber ist.
Für alle die hierfür auch noch Geld in die Hand genommen haben, war es vielleicht auch besonders wichtig, dass wir jedes bei uns gekaufte Zertifikat kostenlos umtauschen.

Damit ist die Aufarbeitung des Heartbleed-Problems bei uns eigentlich abgeschlossen. Abgesehen von den etlichen Zertifikaten, die es nun gilt auszutauschen. Das wird aber weit weniger Stressig als alles was wir bisher in dieser Sache zu tun hatten

Ein Kunde fragte kürzlich per E-Mail wie er denn am besten und automatisiert Seine Datenbanken bei uns sichern kann.

Reflexartig überlegte ich kurz, wie ich seinen Wunsch am besten beantworten kann. Solange bis ich mir vor den Kopf schlug: Der Kunde sichert seine MySQL-Datenbank natürlich genau so wie wir es auch tun würden, nämlich über SSH mittels mysqldump:

Dazu legt man am besten (s)einen SSH-Public-Key in der Datei /homes/{Benutzer}/.ssh/authorized_keys ab und schreibt sich einen Skript, der so etwas wie

ssh -p 622 -o PasswordAuthentication=no {Benutzer}@{Domain} "mysqldump -u{Benutzer} -p{Passwort} {Datenbank}" > {Datenbank}.sql

regelmäßig ausführt. Und fertig.

An den Gedanken, dass wir im normalen Webhosting mittlerweile auch SSH-Zugänge (primär für SCP, SFTP und RSync) rausgeben muss ich mich wohl noch gewöhnen.

Ich hatte schon mehrfach ein Kribbeln in den Fingern und wollte es schon früher hier geschrieben haben, aber so 100% abgeschlossen war die Sache bis dahin nicht. Ab heute gilt das für mich nicht mehr, ich darf schreiben:

Unsere SEPA-Umstellung ist komplett abgeschlossen.

Seit Anfang 2014 haben wir konsequent ausgehende Zahlungen auf SEPA umgestellt und uns dann Mitte Januar auf die Umstellung des Lastschrift-Verfahrens und alles was damit zusammenhängt konzentriert, was auch perfekt funktioniert hat. Heute habe ich dann die ersten Zahlungseingänge (aus SEPA-Lastschriften) auf unserem Konto festgestellt. Herrlich!

Einziger Wermutstropfen: Die Lastschriften haben wir nicht zu dem auf der Rechnung angegebenen Datum ausgelöst, sondern ein paar Tage später. Ich glaube aber nicht, dass das wirklich jemanden stören wird außer mir selbst. Wobei ich auch der jenige war, der diese Verzögerung ein wenig paranoid herbeigeführt hat indem ich jede SEPA-XML-Datei vorab manuell gelesen geprüft habe - vergebens.

Bei der Konvertierung der bestehenden Einzugsermächtigungen in SEPA-Mandate haben wir uns noch einem externen Werkzeug bedient. Den "normalen" Zahlungsverkehr führen wir hingegen mit eigener Software durch, die im wesentlichen ein OOP-Interface für PHP zur Validierung der Zahlungsaufträge und Generierung von SEPA-XML-Dateien bereitstellt. Wer schändlicherweise noch nicht umgestellt hat und/oder an der Software Interessiert ist, darf gerne einen Link zum Repository erfragen. Aktuell kann die Anwendung Zahlungsaufträge (Payment Initiation, "PaIn") nach dem Rulebook DE-2.7 generieren und unterstützt dabei "normale" Überweisungen (pain.001.003.03) ohne Purpose und die drei Lastschrift-Typen (pain.008.003.02) "Basis-Lastschrift" (CORE und COR1) sowie "Firmen-Lastschrift" (B2B). Das gewünschte Ausführungsdatum lässt sich entweder für die gesamte Nachricht und/oder für einzelne Aufträge angeben.

Ich habe gerade eben auf einem Testsystem im Rechenzentrum einen Kernel installiert, der neben normalem TCP auch Multipath-TCP nach RFC 6824 überstützt.

Bei Multipath-TCP werden Datenverbindungen zwischen Client und Server - sofern verfügbar - auf mehrere Internet-Leitungen aufgeteilt um eine höhere Geschwindigkeit aber auch eine gewisse Ausfallsicherheit zu erlangen - grob gesagt so etwas wie Bonding/Trunking auf Layer 4.

Noch gilt das ganze als experimentell und so wird auch dieses Testsystem einige Zeit laufen bevor es dieser Kernel auf einen "richtigen" Webserver schafft. Aber spannend ist dieser Ansatz schon, zumal ich erst kürzlich im Zug über den Hotspot geflucht habe und ein "Fallback" auf eigenes UMTS funktionierte und besonders Multipath-TCP für so ein Szenario perfekt geeignet ist. Denkt man jetzt noch an unseren VPN Gateway, die Möglichkeit diesen auch per TCP anzusprechen und lässt dabei den Umstand, dass man TCP nicht über (MP)TCP tunneln sollte weg, ergibt sich ein nahezu perfektes Anwendungsszenario.

Auch iPhone/iPad-Nutzer könnten sich freuen (sofern MPTCP dort für "normale" Anwendungen und nicht nur Siri zur Verfügung steht), würde doch der Wechsel zwischen Mobilfunknetz und WLAN leichter.

Kleine Notiz für mich selbst:
Wenn schon das Hinzufügen des ersten Slave zu einem frischen Bonding-Interface fehlschlägt mit dem Fehler "Invalid Argument" fehlschlägt, sollte man die MTU der beiden Interfaces prüfen.

Hintergrund:
Für ein internes Projekt wollte ich mehrere VPN-Tunnel in einem Bond zusammenfassen. Auf den VPN-Tunneln selbst ist die MTU wegen des Protokoll-Overhead kleiner als auf normalen Devices, das Bonding-Interface wurde aber mit dem Standard von 1500 Bytes erstellt und versuchte diese Einstellung auf die Slaves zu übernehmen - was nicht ging (dafür habe ich extra Kernel-Quelltext gelesen). Kurz nach dem erstellen des Bonds die MTU auf den kleinsten gemeinsamen Nenner zu setzen schaffte hier Abhilfe.

Wer sich jetzt fragt, wozu das gut sein soll, der darf gespannt sein

Hier im Rechenzentrum in Stuttgart ist bei unserem Dienstleister leider ein Switch defekt, was zu Verbindungsproblemen führen kann. In jedem Falle ist es langsam!

Der Switch wird jetzt ordentlich getauscht und danach sollte alles wieder gut sein - bis dahin bitte etwas Geduld und Verständnis =)

Wer kennt das nicht? Man sitzt bei einem Kaffee im Cafe und schreibt an einem asyncronen SMTP-Client... Da dies ja ein Entwicklungsschritt ist, arbeitet man auf einem vertrauten SMTP-Server und liest beim Testen den SMTP-Dialog mit:

> 220 ******************************************
< EHLO qccore2-test.virtual.tiggersystems.info

> 250-mail.tiggerswelt.net
> 250-PIPELINING
> 250-SIZE 104857600
> 250-VRFY
> 250-ETRN
> 250-XXXXXXXA
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN

Huch? Merkwürdig! Sowohl das "initial Greeting" des Servers und die StartTLS-Erweiterung in den Server-Features sind "geschwärzt". Was soll denn das? Ich weiß zwar mit welchem Server ich mich da verbinde, insofern ist mir das egal, aber warum darf ich denn angeblich kein StartTLS ausführen?

Da der Client explizit dieses Feature für der TLS-Aushandlung prüft also kurz diesen Check auskommentiert und "brute force" StartTLS versucht:

< STARTTLS
> 502 5.5.2 Error: command not recognized

Böse! Ich möchte ja jetzt keine Verschwörungstheorien a la Snowden und PRISM niederschreiben, aber es ist schon sehr merkwürdig, dass der Hotspot der Telekom verhindert, dass eine SMTP-Verbindung per TLS verschlüsselt werden kann.

Ach ja, nur der Vollständigkeit halber: Lege ich dann eine SSL-Verschlüsselte VPN-Sitzung über diese Verbindung funktioniert es sofort und wie gewünscht:

> 220 mail.tiggerswelt.net ESMTP TiggerMail/1.25
< EHLO qccore2-test.virtual.tiggersystems.info

> 250-mail.tiggerswelt.net
> 250-PIPELINING
> 250-SIZE 104857600
> 250-VRFY
> 250-ETRN
> 250-STARTTLS
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
< STARTTLS

> 220 2.0.0 Ready to start TLS
[TLS-Aushandlung]
< EHLO qccore2-test.virtual.tiggersystems.info

> 250-mail.tiggerswelt.net
> 250-PIPELINING
> 250-SIZE 104857600
> 250-VRFY
> 250-ETRN
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN

Ich bin ja bekennender IMAP-Fan. Schon in sehr jungen Jahren (mit 14 oder 15 Jahren) fand ich POP3 und Webmail richtig blöd, wenngleich mich die damalige Internet-Situation etwas an POP3 fesselte.

Ich kann jetzt aber nicht nur Lobes- Hymnen auf dieses Protokoll schwingen, denn eine Sache stieß mir schon übel auf, als ich das erste mal von der technischen Seite her einen Blick auf dieses Protokoll warf:
Es gibt eine Vielzahl grundsätzlich wohldefinierter Server-Antworten ("Responses"), die recht lose oder an ein bestimmtes Kommando über die Verbindung übertragen werden. Das Format ist dabei eigentlich immer

 <ID-or-untagged> <Response> [<Code>] <Response-specific stuff>

allerdings wird es spätestens, wenn man mittels SELECT bzw. EXAMINE eine Mailbox öffnet, denn dann kommen auf einmal die Responses EXISTS, RECENT, FETCH und EXPUNGE ins Spiel und die verhalten sich anders. Dort ist es dann immer im Format

<untagged> <Number> <Response>

 Muss das sein? Wäre es nicht sinnvoller gewesen die Nummern bzw. Anzahlen gleich hinter den Response zu setzen oder die Dinger gleich als "Codes" umzusetzen, so wie es z.B. auch bei UNSEEN, UIDNEXT und UIDVALIDITY ist? Überhaupt sieht dieses Misch-Masch an Responses und Codes beim öffnen eine Mailbox sehr komisch aus.

Das musste jetzt mal raus!