IMAP-Postfächer wachsen mit der Zeit. Irgendwann hat man tausende Mails im Posteingang und in Sent, die Suche wird langsam und die Übersicht geht verloren. cleanup-maildir ist ein Python-Script das Mails nach Alter automatisch in Archiv-Ordner sortiert. Es läuft als Cronjob und arbeitet direkt auf dem Maildir-Verzeichnis.
--age=365 fasst nur Mails an die älter als ein Jahr sind. --archive-folder gibt den Zielordner im IMAP-Postfach an. archive ist der Modus (alternativ delete). Der leere String '' steht für die Inbox, 'Sent/' für die gesendeten Mails.
Das Script legt automatisch Unterordner nach Jahr und Monat an. Die Struktur im Postfach sieht dann so aus:
Bei mehreren Postfächern will man nicht für jeden Benutzer einen eigenen Cronjob-Eintrag pflegen. Ein Wrapper-Script kann die Benutzer, Maildir-Pfade und die Option ob archiviert werden soll aus dem LDAP holen. Das LDAP-Attribut (z.B. autoarchive=1) steuert pro Benutzer ob die Archivierung aktiv ist. So lässt sich die Archivierung zentral verwalten ohne auf jedem Mailserver Cronjobs anzupassen.
Python 3.11+ und kaputte Header
Ab Python 3.11 nutzt cleanup-maildir den strikten RFC-Header-Parser aus email.policy.default. Das führt zu einem Problem: Mails mit fehlerhaften Headern (z.B. Microsoft Exchange Message-IDs wie <[b378dfc5...]@microsoft.com>) lassen das Script mit einem IndexError abstürzen. Alle Mails nach der fehlerhaften werden nicht mehr verarbeitet.
Den Fix dafür habe ich als Pull Request eingereicht. Ein _safe_header()-Wrapper fängt Parse-Fehler ab und überspringt kaputte Header, statt das ganze Script abzubrechen. Bei mir hat das Script vorher bei Mail #8 aufgehört, danach liefen alle 2.986 Mails sauber durch.
Dear colleagues,
Today, at 15:35 UTC+1 on 25 November 2019, we made our final /22 IPv4 allocation from the last remaining addresses in our available pool. We have now run out of IPv4 addresses.
Our announcement will not come as a surprise for network operators - IPv4 run-out has long been anticipated and planned for by the RIPE community. In fact, it is due to the community's responsible stewardship of these resources that we have been able to provide many thousands of new networks in our service region with /22 allocations after we reached our last /8 in 2012.
----------------------------------------------------------------
Recovered IPv4 Addresses and the Waiting List
----------------------------------------------------------------
Even though we have run out, we will continue to recover IPv4 addresses in the future. These will come from organisations that have gone out of business or whose LIR accounts are closed, or from networks that return addresses they no longer need. They will be allocated to our members according to their position on a new waiting list that is now active.
While we therefore expect to be allocating IPv4 for some time, these small amounts will not come close to the many millions of addresses that networks in our region need today. Only LIRs that have never received an IPv4 allocation from the RIPE NCC (of any size) may request addresses from the waiting list, and they are only eligible to receive a single /24 allocation.
LIRs that have submitted an IPv4 request can see their position on the waiting list in the LIR Portal. A new graph has also been published that shows the number of requests on the waiting list and the number of days that the LIR at the front of the queue has been waiting:
https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-waiting-list
----------------------------------------------------------------
Call for Greater Progress on IPv6
----------------------------------------------------------------
This event is another step on the path towards global exhaustion of the remaining IPv4 addressing space. In recent years, we have seen the emergence of an IPv4 transfer market and greater use of Carrier Grade Network Address Translation (CGNAT) in our region. There are costs and trade-offs with both approaches and neither one solves the underlying problem, which is that there are not enough IPv4 addresses for everyone.
Without wide-scale IPv6 deployment, we risk heading into a future where the growth of our Internet is unnecessarily limited - not by a lack of skilled network engineers, technical equipment or investment, but by a shortage of unique network identifiers. There is still a long way to go, and we call on all stakeholders to play their role in supporting the IPv6 roll-out.
At the RIPE NCC, we are here to support our membership and the wider RIPE community in this work. Aside from allocating the IPv6 resources that will be required, we will continue to provide advice, training, measurements and tools to help network operators as they put their deployment plans into action.
We are optimistic and excited to see what the next chapter will bring. So let's get to work - and together, let's shape the future of the Internet.
Best regards,
Everyone at the RIPE NCC
Nö? Vielleicht spannend?!? Für die IPv4 Adresse einer Webseite wird euch so direkt das Resultat des letzten „Scans“ angezeigt. Hin und wieder mal ganz spannend was einen da so anspringt.
Die Zeit ging weiter, die Entwicklung bei BIND und DNS ebenfalls. Daher gibt es nun einen neuen Beitrag, der das aktuelle Setup mit BIND 9.20 auf FreeBSD 15 beschreibt – inklusive sauberer Trennung von authoritative DNS (Port 53) und öffentlichem Resolver (DoT/DoH) sowie reproduzierbaren CLI-Tests für IPv4 und IPv6. Bitte dort weiterlesen.
Meine Tests mit DoT (DNS over TLS) habe ich bereits vor einiger Zeit gestartet. DoT DNS over TLS mit Bind, stunnel und Android 9 Dieses arbeitet noch immer ganz fein auf meinem Smartphone. DoT gefällt mir noch immer um einiges besser als DoH aber auch hier wollte ich nun einmal einen Versuch starten. Zusammen mit nginx und einem etwas angepassten doh-proxy läuft dieses nun auf dem gleichen System.
Im Firefox ist es schnell aktiviert https://ns1.kernel-error.de/dns-query…
Es funktioniert auch, so richtig glücklich macht es mich aber nicht! Natürlich ist die Umsetzung nur etwas für einen kleinen privaten Test. „Schnell“ genug ist es ebenfalls! Zumindest zum Surfen im Internet, dennoch wäre mir eine saubere Implementierung von DoT im resolver vom OS viel lieber. So wie bereits ab Android 9 zu sehen. Vielleicht ändert sich mein Gefühl ja etwas zusammen mit QUIC (HTTP/3)?!?
Meine Geschirrspülmaschine hat mir heute einige Nerven gekostet. Mit einem fröhlichen E-21 im Display war Schluss mit Spülen. Der Fehlercode deutet darauf hin, dass etwas mit der Umwälzpumpe nicht stimmt. Die Maschine ist knapp sechs Jahre alt und läuft hier täglich für einen Vier-Personen-Haushalt, sie hat selten Langeweile. Die Maschine ist baugleich zu Siemens, Neff und Constructa.
Mein erster Schritt war ein Anruf beim nächstgelegenen Serviceanbieter. Dieser sagte mir, dass er die Maschine in einer Woche abholen und bei sich überprüfen könnte. In der Regel wird dann die Umwälzpumpe ausgetauscht, und ich bekäme die Maschine nach zwei bis drei Tagen zurück. Für 200 bis 300 € mehr könnte er mir aber direkt eine neue Maschine liefern und die alte entsorgen. Bei einer so alten Maschine… Warum werden heutzutage nur noch Teile ausgetauscht? Warum soll immer alles neu sein? Warum repariert niemand mehr?
Reparatur
Eine kurze Suche brachte mir eine Explosionszeichnung meiner Spülmaschine. Die Konstruktion sieht sehr überschaubar aus. Letztlich fand ich in der Umwälzpumpe ein Stück Plastikverpackung. Die Pumpe ließ sich fast vollständig zerlegen und reinigen. Jetzt läuft die Maschine wieder, ganz ohne Fehler, insgesamt 40 Minuten Arbeit.
Nachtrag: Pumpe doch kaputt
Einige Monate später hat die Pumpe dann doch aufgegeben. Anscheinend hat das Plastikteil eine Unwucht verursacht, die zum endgültigen Ausfall geführt hat. Falls die Pumpe tatsächlich defekt ist, lässt sich das Ersatzteil über Amazon bestellen. Der Austausch ist einfach, und alles Notwendige ist dabei.
Die gleiche Maschine hatte später auch den Fehler E-15, eine verzogene Dichtung am Pumpentopf. Fragen? Einfach melden.
Mein privates Notebook ist noch immer ein Dell Latitude E6540. Die ab Werk verbaute Intel Centrino Ultimate-N 6300 macht zwar noch immer ihren Job, inzwischen stört mich immer öfter ihr Durchsatz. Maximal soll sie 450 Mbps bringen, dieses schafft sie natürlich nur unter guten Bedingungen. Früher ist mir dieses nicht besonders aufgefallen, durch bessere WLAN APs und schnelleres Internet bremst mich inzwischen meine verbaute WLAN Karte beim Download :-/ das ist doof!
Also einfach neue Karte kaufen, ins Notebook stecken und los gehts.. Naja, fast! Im Latitude können drei PCIe Half MiniCard verbaut werden. Aktuelle WLAN Karten für Notebooks nutzen inzwischen aber M.2 als Schnittstelle zum Notebook. Ebenfalls sind die Anschlüsse der Antennen „kleiner“ geworden. Intel bietet für ihre Produkte auf ihrer Webseite die Option an ihre Produkte miteinander zu vergleichen. >klick<
Um M.2 komme ich nicht herum, wenn ich es mit einem möglichst einfachen Adapter anschließen möchte muss ich darauf achten, dass die neue Karte PCIe spricht. Die Intel Wireless-AC 9260 kann dieses und bietet dazu noch 1,73Gbps. Dazu noch ein Adapter und zwei Antennenadapter. Alles bekommt man schnell für einen kleinen Euro auf Amazon.
Es gibt seit einiger Zeit einen Draft zu Security Policies. Schaut mal hier: https://tools.ietf.org/html/draft-foudil-securitytxt-07 über diesen Weg kann man für seine Domain eine Security Policie veröffentlichen. Dieses inkl. Kontaktdaten einer „Dankeschön“ Seite usw…
Die Idee ist es eine einheitliche Möglichkeit zu schaffen um freundlichen Findern von Sicherheitslücken/Problemen eine einfache und „sichere“ Anlaufstelle zu geben. Wer schon mal ein Löchlein gefunden hat, kennt das Problem. Man sucht eine Kontaktmöglichkeit, scheitert an der Human Firewall oder am technischen Verständnis von seinem Gegenüber. Gibt es es bug bounty oder wird der Informierte ~nervös~?!? Ist die Webseite vielleicht schon kompromitiert und der Hinweis wandert direkt an den Bösewicht? usw. usw. usw…
Diese Probleme soll dieser RFC möglichst einfach erschlagen. Es gibt ein textfile mit dem Namen security.txt unter der jeweiligen Domain im Pfad .well-known, diese ist nach Möglichkeit noch gpg cleartext signiert und beinhaltet alle nötigen Informationen.
Bluetooth-Audio und FreeBSD vertragen sich nicht. Der Bluetooth-Stack wird nicht mehr gepflegt, in OpenBSD wurde er komplett entfernt. Einen Bluetooth-Dongle oder eine eingebaute Bluetooth-Karte dazu zu bringen, sich mit einem Audio-Gerät zu verbinden, funktioniert unter FreeBSD praktisch nicht.
Die Lösung ist ein USB-Dongle, der sich selbst um Bluetooth kümmert: Der Creative BT-W2. Das Gerät meldet sich am Betriebssystem als normale USB-Soundkarte. Das Pairing mit dem Bluetooth-Kopfhörer oder -Lautsprecher macht der Dongle selbständig per Knopfdruck. FreeBSD sieht nur eine Soundkarte, kein Bluetooth.
Das Kernelmodul snd_uaudio kümmert sich um die Erkennung. In der /etc/rc.conf:
kld_list="snd_uaudio"
Nach dem Laden des Moduls erscheint das Gerät im dmesg:
uaudio0: on usbus0
uaudio0: Play: 48000 Hz, 2 ch, 16-bit S-LE PCM format, 2x8ms buffer.
uaudio0: Record: 48000 Hz, 1 ch, 16-bit S-LE PCM format, 2x8ms buffer.
pcm5: on uaudio0
uaudio0: HID volume keys found.
Pairing und Nutzung
Kurz den Knopf am Dongle drücken, er blinkt und verbindet sich mit dem nächsten Bluetooth-Audio-Gerät in Reichweite. Kopfhörer, Headsets, Lautsprecher und Mikrofone funktionieren. Die Qualität reicht auch für Telefonie, Latenz und Codec sind in Ordnung.
Das Audio-Device ist je nach Systemkonfiguration /dev/dsp5 oder ein anderer Index. Mit cat /dev/sndstat lässt sich prüfen welches Device der BT-W2 bekommen hat.
Nicht die eleganteste Lösung, aber sie funktioniert zuverlässig. Solange der Bluetooth-Stack auf FreeBSD nicht wiederbelebt wird, ist ein Dongle wie der BT-W2 der pragmatischste Weg.
Es gibt Momente im Leben eines Sysadmins, in denen man kurz innehalten und sich fragen sollte, ob alles noch so läuft wie geplant. Einer dieser Momente war, als mir der Typ an der Domino’s Theke eine Goldcard in die Hand drückte.
Nachtschichten und Pizza
Wer regelmäßig Nachtschichten im Serverraum schiebt, kennt das Dilemma. Es ist 23 Uhr, der Storage-Umbau läuft, die Migration zieht sich und der letzte vernünftige Bissen war irgendwann mittags. Döner hat zu, der Kühlschrank im Büro gibt maximal eine traurige Käsescheibe her. Aber Domino’s liefert. Immer. Egal ob Mitternacht oder drei Uhr morgens.
Irgendwann kennen die einen. Erst am Telefon („Ach, Sie schon wieder, das Übliche?“), dann an der Theke. Man wird Stammkunde, nicht weil man Domino’s so wahnsinnig toll findet, sondern weil die halt offen haben wenn sonst niemand mehr offen hat. Pragmatismus schlägt Kulinarik, vor allem um zwei Uhr nachts mit einer Hand am Terminal.
Die Goldcard
Jedenfalls drückte mir eines Abends der Filialleiter kommentarlos eine goldene Plastikkarte in die Hand. Domino’s Goldcard. Heißt im Klartext: Ab sofort gibt es auf jede Bestellung Rabatt. Weil man so oft da war. Weil man so viel bestellt hat. Weil man offenbar zu den besten Kunden der Filiale gehört.
Da steht man dann mit seiner Goldcard und fragt sich: Ist das jetzt eine Auszeichnung oder eher ein Hilferuf? Wahrscheinlich beides. Aber immerhin, die Server liefen am nächsten Morgen und die Pizza war warm. Prioritäten.
Falls du auch regelmäßig dein Rechenzentrum mit Pizza am Laufen hälst und Fragen hast, kannst du mich gerne fragen. Zur Pizza kann ich leider nicht mehr viel sagen, die Filiale hat inzwischen zugemacht. Wahrscheinlich nachdem ich weggezogen bin.
Vor einigen Jahren habe ich bereits etwas zu Microsoft Office Outlook Autodiscover geschrieben. Ich setze es noch immer in ähnlicher Form ein. Hier der aktuelle Stand.
Nginx-Konfiguration
Hinter autodiscover.kernel-error.de steht ein Nginx, der unter /Autodiscover/Autodiscover.xml die Konfiguration für verschiedene Maildomains ausliefert. Die Location ist überschaubar:
Jede Anfrage nach /autodiscover/autodiscover.xml wird an autodiscover.php weitergeleitet. Das Script liest die im POST übermittelte E-Mail-Adresse, prüft sie und liefert die XML-Antwort mit IMAP- und SMTP-Einstellungen zurück:
Ohne diese Einträge muss man im Outlook manuell den Haken setzen bei „Gleiche Einstellungen wie für den Posteingangsserver verwenden“. Das überfordert erstaunlich viele Anwender.
Mehrere Domains per SRV-Record
Damit Autodiscover nicht nur für kernel-error.de funktioniert, gibt es in den anderen DNS-Zonen SRV-Records, die auf die zentrale Autodiscover-Domain verweisen:
$ dig _autodiscover._tcp.kernel-error.com IN SRV +short
0 0 443 autodiscover.kernel-error.de.
Outlook zeigt beim ersten Mal eine Warnmeldung, ob man dem Verweis folgen möchte:
Einmal bestätigt, ist die Konfiguration abgeschlossen. Man könnte die Meldung auch per Registry-Key unterdrücken, aber für die meisten Benutzer reicht ein Klick.
Update März 2026: Aufgeräumt und abgesichert
Das Grundprinzip funktioniert seit 2019 unverändert. Outlook bekommt per POST seine Konfiguration, der Benutzer muss nur E-Mail-Adresse und Passwort eingeben. Ein paar Dinge habe ich aber überarbeitet.
PHP-Script: GET-Requests und fehlende Eingaben abfangen
Das alte Script hat bei GET-Requests oder einem leeren POST-Body mit HTTP 500 geantwortet. Es versuchte auf eine Variable zuzugreifen, die bei fehlendem XML-Body nicht existiert. Monitoring-Tools und neugierige Browser liefen damit gegen die Wand.
Die korrigierte Version prüft jetzt sauber:
<?php
// Nur POST erlauben
if ($_SERVER["REQUEST_METHOD"] !== "POST") {
header("HTTP/1.1 405 Method Not Allowed");
header("Allow: POST");
exit;
}
$request = file_get_contents("php://input");
preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $request, $email);
if (empty($email[1]) || filter_var($email[1], FILTER_VALIDATE_EMAIL) === false) {
header("HTTP/1.1 400 Bad Request");
exit;
}
// XSS-Schutz: E-Mail fuer XML-Ausgabe escapen
$loginName = htmlspecialchars($email[1], ENT_XML1, "UTF-8");
GET liefert jetzt 405, ein POST ohne gültigen Body gibt 400. Die E-Mail-Adresse wird zusätzlich mit htmlspecialchars() escaped, bevor sie in die XML-Antwort geschrieben wird.
Nginx: Kein Cache für dynamische Antworten
In der ursprünglichen Konfiguration steckt fastcgi_cache MYAPP mit 60 Minuten Gültigkeit. Das ist für Autodiscover falsch. Die Antwort enthält die E-Mail-Adresse des anfragenden Benutzers als <LoginName>. Mit Cache bekommt der zweite Benutzer die Adresse des ersten. Ohne Cache:
Das ~* macht den Match case-insensitive, kürzer als die alte Regex mit (?:a|A).
Thunderbird Autoconfig auf dem gleichen Host
Inzwischen bedient autodiscover.kernel-error.de nicht mehr nur Outlook, sondern auch Thunderbird per Autoconfig. Dazu reicht eine zusätzliche Location im gleichen Server-Block:
location /mail/ {
alias /usr/local/www/autoconfig-mail/mail/;
}
Thunderbird fragt https://autoconfig.<domain>/mail/config-v1.1.xml. Für jede Maildomain gibt es einen autoconfig.* CNAME und einen eigenen HTTPS-Server-Block. Outlook nutzt weiterhin den POST-Endpoint, Thunderbird die statische XML.