Revert "Translate all posts to German with personal blog style"

This reverts commit cc7ba433d4.

content/posts/blocking-invalid-rcpt-postfix.md

@@ -1,98 +1,126 @@
 +++
 date = '2025-08-01T10:03:15+02:00'
 draft = false
-title = 'Backscatter ade: Ungültige Empfänger vor dem Exchange abfangen'
+title = 'Blocking Invalid Recipients Before They Reach Your Exchange Server'
+
 
 [cover]
 image = "/imgs/email-route.jpg"
-alt = "E-Mail App Icon auf blauem Hintergrund"
+alt = "Email App icon on blue background"
 caption = ""
 +++
 
-Neulich hatte ich ein richtig fieses Problem: **Backscatter**. Einer unserer Mail-Gateways landete auf der **backscatter.org**-Blacklist, weil wir Bounce-Nachrichten an gefälschte Absender geschickt haben. Ja, genau so läuft das: man will ja eigentlich nur Mails zustellen und plötzlich ist man selber der Spammer.
+Recently, I had to deal with a serious problem: **backscatter**.  
+One of our mail gateways ended up listed on the **backscatter.org** blacklist for sending bounce messages to forged senders.  
 
-Nach einem Blick in die Logs war mir klar: Unser System war gegen Backscatter-Attacken so gut geschützt wie ein Fahrradschloss aus Pappe. Also musste was passieren.
+After checking the logs, I quickly realized that our system wasn't actually protected against backscatter attacks, so I had to do something about it.
 
-## Was zur Hölle ist Backscatter?
 
-Backscatter ist Müll, den dein Mail-Server **verschickt, nachdem** er eine Nachricht angenommen hat – meistens in Form eines **Non-Delivery Reports (NDR)** oder Bounces an eine **gefälschte Absenderadresse**.
 
-Passiert so:
+## What Even Is Backscatter?
 
-- Ein Spammer schickt 'ne Mail mit ner **fake "Von"-Adresse** (oft von nem armen Unschuldigen).
-- Dein Server **nimmt die Mail an**, stellt aber später fest: "Hoppla, den Empfänger gibt's gar nicht."
-- Dein Server schickt nen **Bounce** an die gefälschte Absenderadresse – und trifft damit den Falschen.
+Backscatter is unwanted email that your mail server sends **after** receiving a message, usually in the form of a **non-delivery report (NDR)** or **bounce** to a **forged sender address**.
 
-Und Zack, dein Server versendet Spam, ohne es zu wollen. Willkommen im Club.
+It happens when:
 
-## Das Problem bei uns
+- A spammer sends email with a **fake "From" address** (often an innocent third party).
+- Your mail server **accepts** the message first, but later discovers it’s undeliverable.
+- Your server sends a **bounce** to the forged address, hitting an innocent person instead of the spammer.
 
-Unser Mail-Gateway leitet hauptsächlich Mails an mehrere interne Exchange-Cluster weiter. Klar, wir haben eine Liste mit gültigen Domains – Postfix nimmt nur Mail für diese Domains an.
+This makes your server appear to be sending spam, even though you're just bouncing bad mail.
 
-**Das Problem?** Postfix wusste nicht, welche einzelnen Empfänger auf den Exchange-Servern gültig sind. Also hat es fröhlich Mails für **nicht existierende Benutzer** angenommen, um sie dann später zu bouncen. Klassischer Backscatter.
 
-## Das Ziel
 
-Wir wollten Mails **während der SMTP-Session** ablehnen – idealerweise direkt nach dem `RCPT TO`-Befehl, wenn der Empfänger auf dem Exchange nicht existiert.
+## The Problem in Our Setup
 
-Dann kriegt der Sender sofort einen Korb und wir müssen erst gar keinen Bounce generieren. Win-Win.
+Our mail gateway mostly relays mail to multiple internal Exchange Server clusters.  
+We have a list of valid domains configured, so Postfix will only accept mail for those domains.  
 
-## Mögliche Lösungen (und warum ich sie verworfen hab)
+**The problem?**  
+Postfix didn't know which individual recipients were valid on the downstream Exchange servers.  
+That meant it would happily accept messages for **nonexistent users**, only to later bounce them, classic backscatter behavior.
+
+
+
+## The Goal
+
+We needed to reject mail **during the SMTP session**, ideally right after the `RCPT TO` command, if the recipient didn't exist on the Exchange servers.
+
+That way, the sending server would get the rejection immediately, and we would never have to generate a bounce message.
+
+
+
+## Possible Solutions I Considered
 
 ### **1. relay_recipient_maps**
-Dafür hätte ich ne **komplette Liste aller gültigen Empfänger** in Postfix pflegen müssen. Klar, geht. Aber dann müsste ich ein Skript schreiben, das die Liste regelmäßig aus Active Directory synchronisiert.
+This would require maintaining a **full list of valid recipients** in a Postfix lookup table.  
+It works well, but means writing and maintaining a script to **sync the list from Active Directory** on a regular basis.  
 
-Für uns war das zu viel Gefrickel, zu fehleranfällig und zu nervig zu warten.
+For us, this was too much custom scripting, too fragile, and too messy to maintain.
 
-### **2. virtual_mailbox_maps mit LDAP**
-LDAP-Lookups direkt gegen Active Directory, um Empfänger in Echtzeit zu prüfen. Klingt erstmal gut, aber:
 
-- Mehr Komplexität und Abhängigkeiten.
-- Potenzielle Sicherheitsrisiken.
-- Hat nicht so richtig in unsere Umgebung gepasst.
 
-Also auch gestrichen.
+### **2. virtual_mailbox_maps with LDAP**
+Another approach would be using **LDAP lookups** directly against Active Directory to verify recipients in real-time.  
 
-## Die Lösung: `reject_unverified_recipient`
+This can work in some setups, but:
+- It adds complexity and dependencies.
+- It can introduce security concerns.
+- It didn’t fit well with our environment.
 
-Beim Durchlesen der **Postfix Address Verification Howto** bin ich über `reject_unverified_recipient` gestolpert – und dachte sofort: "Digga, genau das brauch ich!"
+So I ruled it out.
 
-### **Wie es funktioniert**
 
-Wenn ne eingehende SMTP-Session die `RCPT TO`-Phase erreicht:
 
-1. Postfix checkt, ob `reject_unverified_recipient` für die Empfängerdomäne aktiv ist.
-2. Wenn ja, wird kurz **beim downstream Mail-System angefragt**, ob die Adresse existiert.
-3. Antwort vom downstream System:
-   - **User existiert** → Postfix macht weiter.
-   - **User existiert nicht** → Postfix **lehnt sofort ab** mit:
+## The Solution: `reject_unverified_recipient`
+
+While reading through the **Postfix Address Verification Howto**, I came across the `reject_unverified_recipient` option - bling! - exactly what I needed.
+
+
+
+### **How It Works**
+
+When an incoming SMTP session reaches the `RCPT TO` stage:
+
+1. Postfix checks if `reject_unverified_recipient` is enabled for the recipient domain.
+2. If yes, it temporarily **probes the downstream mail system** to see if the recipient address exists.
+3. If the downstream system says:
+   - **User exists** → Postfix continues processing.
+   - **User does not exist** → Postfix **rejects immediately** with:
      ```
      550 5.1.1 <user@example.de>: Recipient address rejected: User unknown
      ```
 
-Weil die Ablehnung **während des SMTP-Dialogs** passiert, wird gar kein Bounce generiert. Backscatter ade!
+Because the rejection happens **during SMTP**, no bounce is generated, and backscatter is avoided entirely.
 
-## Umsetzung in ISPConfig
 
-Bei uns laufen die Mail-Gateways mit **Postfix** und **ISPConfig** als Verwaltungsoberfläche. Also hab ich ne neue Konfigurationsoption in ISPConfig eingebaut, mit der man `reject_unverified_recipient** **pro Domain** steuern kann – plus einen **Validation Server** für den downstream-Server.
+## Implementation in ISPConfig
 
-### Validation Server für die Empfängerprüfung
+In our case, the mail gateways run **Postfix** with **ISPConfig** as the management interface.  
+I implemented a new configuration option in ISPConfig for **per-domain control** of `reject_unverified_recipient`, along with a **validation server** to specify for the downstream validation server.
 
-Wichtiges Detail: Exchange-Server können standardmäßig keine Empfänger über SMTP-Port `25` validieren. Man muss die Funktion erst auf dem Exchange aktivieren und den Hub Transport Service nutzen – der läuft standardmäßig auf Port `2525`.
+### Specifying a Validation Server for Recipient Verification
 
-Unbedingt den Zugriff auf diesen Port einschränken! Der erlaubt nämlich anonyme Logins für die Empfängervalidierung – das will man nicht in der freien Wildbahn haben.
+One important detail is that Exchange servers cannot validate recipients over the default SMTP transport on port `25`. To enable recipient validation, you need to activate it on the Exchange server and use the Hub Transport service, which by default runs on port `2525`.
 
-> **Achtung:** Das ändert nichts an deinem normalen Mail-Flow. Nur die SMTP-Probes für die Empfängerprüfung gehen an diesen Validation Server.
-> Postfix macht das mit der `address_verify_transport_maps`-Option.
+Make sure to restrict access to this port, as it requires anonymous login specifically for recipient validation, you don't want that exposed broadly.
 
-Für die Performance hab ich noch nen lokalen Cache auf dem Gateway eingerichtet (`address_verify_map`), damit nicht ständig dieselben Empfänger neu geprüft werden. Spart Nerven und Resourcen.
+> **Note:** This setup does not affect your regular mail flow. Only the SMTP probes used for verifying recipients are sent to this validation server.  
+> Postfix enables this behavior with the `address_verify_transport_maps` option.
 
-Jetzt können wir für alle Domains, die eine Empfängerprüfung brauchen, das Ding im Panel anschalten und Postfix ans richtige **Validation Transport** schicken.
+To optimize performance and reduce unnecessary verification probes for addresses that have already been checked, I configured a local cache on the mail gateway using the `address_verify_map` option. This way, repeated probes for the same recipient are avoided.
 
-## Das Ergebnis
+Now, for domains that need recipient verification, we can enable it in the panel and point Postfix to the appropriate **validation transport**.
 
-Seit `reject_unverified_recipient` aktiv ist und auf die Exchange-Cluster zeigt, ist der Backscatter komplett weg. Wir nehmen keine Mails mehr für ungültige Empfänger an. Feierabend.
 
-## Fazit
+## The Result
+
+After enabling `reject_unverified_recipient` and pointing it at the Exchange clusters, the backscatter stopped completely.  
+We were no longer accepting messages for invalid recipients.
+
+## Conclusion
+
+If your Postfix server is acting as a relay for Exchange (or any downstream mail system) and you're struggling with **backscatter spam**, enabling `reject_unverified_recipient` can be a clean and effective fix.
+
+It avoids maintaining large static recipient maps, works dynamically, and ensures that invalid mail is rejected **before** it ever gets into your system.
 
-Wenn dein Postfix als Relay für Exchange (oder ein anderes downstream-Mail-System) läuft und du **Backscatter-Spam** loswerden willst: `reject_unverified_recipient` ist der Weg. Sauber, dynamisch, keine großen statischen Listen – und vor allem: die Drecksmail kommt erst gar nicht rein.

content/posts/dovecot-index-cache-issues.md

@@ -1,76 +1,73 @@
 +++
 date = '2025-05-18T11:34:09+02:00'
 draft = false
-title = 'Wenn der Dovecot-Index durchknallt'
+title = 'Dovecot Index Cache Issues'
 
 [cover]
 image = "/imgs/dove.jpg"
-alt = "Tauben auf nem Dach"
-caption = "Die Tauben auf dem Bild haben übrigens nix mit Dovecot zu tun. Fand ich nur passend."
+alt = "Bunch of Doves on a roof"
+caption = ""
 
 +++
 
-# Wenn `dovecot.index.cache` dich in den Wahnsinn treibt
-
-Letztens hab ich ein altes Mail-System in sein neues Zuhause umgezogen. Nach der Migration check ich die Logs – und seh Warnungen wie diese:
+# Understanding `dovecot.index.cache`
 
+I recently migrated an old mail server system into its new home. After the migration, I checked the logs and noticed some warnings that looked like this:
 ```
 May 17 11:23:13 server1 dovecot: dsync-local(user@domain.tld)<cRjZCwGnKWiIvicA2dm5Tw>: Error: Mailbox INBOX: mmap(size=511310568) failed with file /var/vmail/domain.tld/user/Maildir/dovecot.index.cache: Cannot allocate memory
 ```
+The error indicates that the `dovecot.index.cache` file is too big to process, and Dovecot cannot allocate enough memory to handle it. 
 
-Übersetzung: Die `dovecot.index.cache`-Datei ist so fett, dass Dovecot nicht genug Speicher hat, um sie zu verarbeiten. Ja, **500 MB** für 'ne Index-Datei. Das ist kein Index mehr, das ist ein Roman.
+# What Are `dovecot.index.cache` Files?
 
-## Was Sind `dovecot.index.cache`-Dateien Überhaupt?
+Dovecot, the most popular IMAP server, uses a set of index files (`dovecot.index`, `dovecot.index.cache`, `dovecot.index.log`, etc.) to speed up mailbox access. The file I had to deal with stores cached message metadata (headers, flags, and preview text) so Dovecot does not have to read each message file in the mailbox every time.
 
-Dovecot, der beliebteste IMAP-Server auf diesem Planeten, benutzt Index-Dateien (`dovecot.index`, `dovecot.index.cache`, `dovecot.index.log`, etc.), um den Zugriff auf Postfächer zu beschleunigen. Die Datei, die mir Kopfschmerzen bereitet hat, speichert gecachte Nachrichten-Metadaten (Header, Flags, Vorschautext). So muss Dovecot nicht jedes Mal alle Mails durchforsten, wenn du dein Postfach öffnest.
+Over time, the `dovecot.index.cache` file can grow very large or become outdated. Here are a few reasons why this happens:
 
-Mit der Zeit kann die `dovecot.index.cache` allerdings fett werden oder aus der Spur laufen. Hier ein paar Gründe:
+### During Normal Operation
 
-### Im Normalbetrieb
+- Deleted or moved messages may leave behind unused metadata.
+- Corrupt or unreferenced entries might accumulate if a process is interrupted.
+- Stale data can hang around for years if not explicitly purged.
 
-- Gelöschte oder verschobene Mails hinterlassen verwaiste Metadaten.
-- Korrupte Einträge sammeln sich an, wenn mal ein Prozess abstürzt.
-- Datenmüll kann jahrelang rumgammeln, wenn niemand aufräumt.
+### After a Migration
 
-### Nach ner Migration
+Migrations are particularly prone to creating out-of-sync or bloated index files because:
 
-Migrationen sind besonders fies, weil:
+- **File timestamps and UIDs change**: Dovecot's cache is based on assumptions about message state. A migration (e.g. via `rsync` or `imapsync`) may change those assumptions, causing the cache to mismatch the actual message data.
+- **Index format/version mismatch**: If you switch Dovecot versions between servers, the format of `.index.cache` might be incompatible or inefficient.
+- **Partial cache rebuilds**: After a migration, Dovecot may try to reuse old cache files that no longer reflect the real contents of the mailbox, leading to odd behavior or performance issues.
 
-- **Datei-Timestamps und UIDs ändern sich**: Dovecots Cache basiert auf Annahmen über den Zustand der Nachrichten. Eine Migration (z.B. via `rsync` oder `imapsync`) kann diese Annahmen über den Haufen werfen.
-- **Index-Format/Version-Konflikte**: Wenn du zwischen den Servern verschiedene Dovecot-Versionen hast, kann das Format von `.index.cache` inkompatibel sein.
-- **Partielle Cache-Neubauten**: Dovecot versucht, alte Cache-Dateien weiterzuverwenden, die nicht mehr zum aktuellen Inhalt des Postfachs passen. Chaos pur.
+# How to Deal with These Files
 
-## Wie Werd Ich Die Dinger Los?
+After migrating to the new servers, I encountered a few of these messages in the log, so I had to search through and find all users affected by this. Since these large files not only consume unnecessary disk space but also affect performance and cause `dsync` issues, I had to do something about it.
 
-Nach der Migration hatte ich einige dieser Meldungen im Log. Also musste ich alle betroffenen User finden und handeln. Diese riesigen Dateien fressen nicht nur Plattenplatz, sondern killen auch die Performance und verursachen `dsync`-Probleme.
+## Is It Safe to Delete These Files?
 
-### Kann Ich Die Einfach Löschen?
+Short answer: **Yes** — it's safe to delete all `dovecot.index*` files inside a user's Maildir.
 
-Kurze Antwort: **Ja** – du kannst alle `dovecot.index*`-Dateien im Maildir eines Benutzers löschen.
+Dovecot will automatically regenerate the indexes when needed. This will result in a small delay the first time a user accesses their mailbox after deleting these files, but performance will return to normal quickly.
 
-Dovecot baut die Indizes bei Bedarf automatisch neu auf. Klar, beim ersten Login nach dem Löschen gibt's kurz nen kleinen Lag, aber danach läuft alles wieder geschmeidig.
-
-### Wie Finde Ich Die Schwergewichte?
-
-Erstmal checken, was bei dir als "groß" gilt. Ich hab mich auf Dateien über 100 MB konzentriert:
+## How to Find and Clean Up Large Index Files
 
+First, you should check what "large" means for your setup. I checked for files that are larger than 100 MB in size using the following command:
 ```bash
 find /var/vmail -type f -name "dovecot.index.cache" -size +100M -exec ls -lh {} \;
 ```
-
-Nachdem ich die Kandidaten identifiziert hatte, bin ich ins Maildir des Users und hab die Dinger plattgemacht:
-
-```bash
+After validating these files and users, I then moved into the user’s Maildir and removed the files:
+```
 cd /var/vmail/domain.tld/affecteduser/Maildir/
 rm dovecot.index*
 ```
+## What Else Can I Do?
 
-### Gibt's Auch Ne Sanftere Methode?
+There’s another way to deal with large index files: you could increase the virtual memory limit that Dovecot is allowed to use, which is controlled by the `default_vsz_limit` in Dovecot’s configuration files. 
 
-Klar. Du könntest auch das virtuelle Speicherlimit für Dovecot erhöhen (`default_vsz_limit`). Oder die Einstellungen `mail_cache_fields` und `mail_never_cache_fields` anpassen, damit der Cache gar nicht erst so fett wird.
+Another option to prevent future bloat of these files would be adjusting the `mail_cache_fields` and `mail_never_cache_fields` in the configuration.
 
-Ich hab mich fürs Löschen entschieden, weil die Dateien schon vor der Migration so monströs waren. Nach der Neugenerierung sind die Dinger deutlich kleiner. Mal sehen, ob das Thema wiederkommt.
+I decided to delete these files for affected users because these files had grown so large before migrating to the new setup. After regenerating, the files are much smaller, and time will tell if this becomes an issue again.
 
-## Fazit
+# Conclusion
+
+If you encounter these warnings in your logs, it's worth checking the `dovecot.index.cache` files and dealing with them. Cleaning them up is safe and easy — Dovecot will take care of rebuilding what it needs.
 
-Wenn du diese Warnungen in deinen Logs siehst: Check die `dovecot.index.cache`-Dateien und werd sie los. Aufräumen ist sicher und einfach – Dovecot kümmert sich um den Rest. Und denk dran: Ein gut gepflegter Cache ist ein glücklicher Cache.

content/posts/google-groups-spam.md

@@ -1,44 +1,47 @@
 +++
 date = '2025-10-10T09:26:56+02:00'
 draft = false
-title = 'Google Groups Spam – Wenn Google zum Spam-Schleuder wird'
+title = 'Google Groups Spam'
 
 [cover]
 image = "/imgs/google-spam.jpg"
-alt = "Google in bunten Farben auf dunklem Hintergrund"
+alt = "Google in bright colors and dark background"
 caption = ""
 +++
 
-# Dieses Google Groups Problem nervt
+# Understanding the Google Groups Spam Problem
 
-Im letzten Jahr hab ich nen deutlichen Anstieg von Spam bemerkt, der über Google Groups reingekommen ist. Das Ding ist: Google Groups ist von Haus aus so designed, dass Spammer es leicht haben. Die ballern ihre Scheiße über legitime Google-Mail-Server – und das macht's verdammt schwer, das Zeug zu filtern.
+Over the past year, I've noticed a significant increase in spam messages originating from Google Groups. This issue stems from the way Google Groups is designed: It gives spammers an easy way to distribute large volumes of unwanted mail using legitimate Google mail servers, which makes filtering much harder.
 
-## Warum passiert das?
+## Why it Happens
 
-Google Groups hat ein paar grundlegende Design-Probleme, die es für Spammer besonders attraktiv machen:
+There are a few fundamental problems with how Google Groups works that make it particularly attractive to spammers:
 
-- **Kein Opt-in nötig**: Spammer können einfach jede E-Mail-Adresse zu ner Google Group hinzufügen. Ohne Rückfrage. Ohne Bestätigung.
-- **Austreten? Fehlanzeige**: Viele Spam-Gruppen sind privat. Als Opfer kannst du nicht mal auf die Gruppenseite, um dich auszutragen. Du bist drin, ob du willst oder nicht.
-- **Auto-Responder machen's schlimmer**: Manche Gruppen haben automatisierte Mail-Systeme drin (Ticket-Systeme, Abwesenheitsnotizen). Wenn die auf die ursprüngliche Spam-Mail antworten, geht die Antwort wieder an alle Gruppenmitglieder. Spam-Superspreader quasi.
+- **No opt-in required**: Spammers can freely add any email address to a Google Group without the recipient's consent.
 
-## Das Problem und mein Ansatz
+- **Unsubscribing is often impossible**: Many spam groups are set to private, meaning that victims cannot even access the group page to unsubscribe.
 
-Beim Analysieren der Mails ist mir aufgefallen: Einige legitime Organisationen nutzen Google Groups auch für Newsletter oder Ankündigungen. Also einfach den kompletten Google-Groups-Traffic blockieren? Keine gute Idee – zu viele False Positives.
+- **Amplified spam through auto-responders**: Some of these groups include automated mail systems (like ticketing or vacation responders). When these systems reply to the initial spam message, the responses are redistributed to all group members multiplying the traffic in unwanted mails.
 
-Also hab ich mir was überlegt: Eine Lösung, die direkt in **Rspamd**, unserem Spam-Filter, eingreift:
+## The Challenge and Approach
 
-- **Custom Lua Plugin**: Erkennt Nachrichten aus Google Groups und vergibt ein eigenes Symbol.
-- **Composite Rules**: Kombiniert dieses Symbol mit anderen Spam-Indikatoren, um zu entscheiden, ob die Mail wirklich Spam ist.
+While analyzing these messages, I discovered that several legitimate organizations also use Google Groups to distribute newsletters or announcements. That means simply blocking all mail coming from Google Groups would cause false positives and disrupt valid communication.
 
-So zielen wir gezielt auf die missbräuchlichen Muster ab, ohne legitime Google-Groups-Nutzung zu bestrafen.
+To handle this more effectively, I developed a solution that integrates directly with Rspamd, our spam filtering system:
 
-## Ran an die Tasten
+- **Custom Lua plugin**: Detects messages originating from Google Groups and assigns a custom symbol.
 
-Ich hab ein kleines Lua-Plugin für Rspamd gebaut, das Nachrichten aus Google Groups erkennt und mit einem Symbol taggt. Mit Composite Rules wird dann entschieden, ob die Mail als Spam durchgeht oder nicht.
+- **Composite rules**: Use this symbol, combined with other spam indicators, to decide whether a message should be classified as spam.
 
-### Schritt 1: Das Lua-Plugin bauen
+This approach allows us to target the abusive patterns specifically, without penalizing legitimate use of Google Groups.
 
-Ab nach `/etc/rspamd/plugins.d/kits_header_google_group.lua`:
+## Technical Configuration
+
+To tackle the Google Groups spam issue, I built a small custom Lua plugin for Rspamd that detects messages originating from Google Groups and assigns a custom symbol to them. Once tagged, we can use composite rules to decide whether a message should be treated as spam based on additional indicators.
+
+### Step 1: Create the Custom Lua Plugin
+
+Start by creating a new file at `/etc/rspamd/plugins.d/kits_header_google_group.lua`:
 
 ```lua
 rspamd_config:register_symbol{
@@ -63,50 +66,51 @@ rspamd_config:register_symbol{
 }
 ```
 
-Das Plugin sucht nach:
+This plugin checks for either of the following headers:
 
-- `X-Google-Group-Id` Header
-- `List-Unsubscribe` Header mit `googlegroups` drin
+- `X-Google-Group-Id`
+- `List-Unsubscribe` containing the string `googlegroups`
 
-Wenn einer der beiden gefunden wird, gibt's das Symbol `KITS_HEADER_GOOGLE_GROUP`.
+If either is present, the message is tagged with the symbol `KITS_HEADER_GOOGLE_GROUP`.
 
-### Schritt 2: Plugin aktivieren
+### Step 2: Enable the Plugin
 
-Dann noch ein leeres Config-File anlegen unter `/etc/rspamd/modules.d/kits_header_google_group.conf`:
+Next, register a module with the same name by creating an empty configuration file at `/etc/rspamd/modules.d/kits_header_google_group.conf`:
 
 ```bash
-# Leere Config, um das Lua-Plugin zu aktivieren
+# Empty config to enable lua plugin
 kits_header_google_group { }
 ```
 
-Ab jetzt wird jede Mail aus Google Groups mit `KITS_HEADER_GOOGLE_GROUP` getaggt und bekommt 'nen Score von 0,1.
+At this point, every email that originates from a Google Group will be tagged with the symbol `KITS_HEADER_GOOGLE_GROUP` and adds a score of 0.1.
 
-### Schritt 3: Composite Rules bauen
+### Step 3: Create Composite Rules
 
-Jetzt die Composite Rules definieren. Ab damit nach `/etc/rspamd/override.d/composite.conf`:
+The next step is to define composite rules that evaluate whether a tagged message is likely to be spam. Create the following entries in `/etc/rspamd/override.d/composite.conf`:
 
 ```bash
-# Google Group Ursprung mit Bulk oder Freemail
+# Google Group origin with bulk or freemail origin
 KITS_GOOGLE_GROUP_BAD {
   expression = "KITS_HEADER_GOOGLE_GROUP and (DCC_REJECT | FUZZY_BULK | FREEMAIL_FROM)";
   score = 8.0;
 }
 
-# Google Group Ursprung mit Bulk und Freemail
+# Google Group origin with bulk and freemail origin
 KITS_GOOGLE_GROUP_WORST {
   expression = "KITS_HEADER_GOOGLE_GROUP and (DCC_REJECT | FUZZY_BULK ) and FREEMAIL_FROM";
   score = 20.0;
 }
 ```
 
-Die Regeln geben höhere Scores für Mails, die aus Google Groups kommen **und** bekannte Spam-Indikatoren haben wie `DCC_REJECT`, `FUZZY_BULK` oder `FREEMAIL_FROM`.
+These rules assign higher scores to messages that originate from Google Groups and match known spam indicators such as `DCC_REJECT`, `FUZZY_BULK`, or `FREEMAIL_FROM`.
 
-> Die Namen, Scores und Logik sind auf meine Umgebung zugeschnitten. Passt die Werte immer an euer Setup an und testet vorher!
+> The naming scheme, scores, and logic here are tailored to my environment. Always adjust the scoring and expressions to fit your setup and verify changes before applying them.
 
-## Fazit
+## Conclusion
 
-Nachdem das Ding live war, ist der Spam aus Google Groups deutlich zurückgegangen. Legitime Mails von Unternehmen kamen weiterhin durch, der unerwünschte Group-Spam wurde aber effektiv von Rspamd markiert oder weggesperrt.
+After deploying this configuration, the amount of spam originating from Google Groups dropped noticeably. Legitimate messages from companies still passed through correctly, while unwanted group spam was effectively flagged or quarantined by Rspamd.
 
-Wenn du nen Mail-Server betreibst, weißt du: Spam bekämpfen ist ein ewiger Kampf. Aber mit Rspamd hat man zum Glück richtig gute Werkzeuge an der Hand.
+If you're running a mail server, fighting spam is one of the more tedious and ongoing challenges. Thankfully, with Rspamd, we have some of the best and most flexible spam-fighting tools available.
+
+Battling spam will always be a cat-and-mouse game, and I'm sure spammers will find new and clever ways to distribute unwanted mail sooner rather than later, but Rspamd will be here to help. I hope to share more useful posts in the future about keeping our mail systems clean with Rspamd.
 
-Spammer werden immer neue Wege finden, ihren Müll zu verteilen – das ist Katz und Maus. Aber Rspamd ist und bleibt ne verdammt gute Maus.

content/posts/my-first-post.md

@@ -1,27 +1,32 @@
 +++
 date = '2025-05-11T20:13:49+02:00'
 draft = false
-title = 'Hallo Welt!'
+title = 'Introduction'
 +++
 
-# Hallo und Herzlich Willkommen!
+# Welcome to My Blog!
 
-Ich bin **Demian**, von Beruf **Sysadmin**, aus Leidenschaft **E-Mail-Infrastruktur-Nerd** und ab und zu auch mal **Open-Source Contributor**. Ja, ich bin einer von denen, die sich freiwillig damit rumärgern, wenn der Mailserver spinnt. Hier blogge ich über alles, was mir auf dem Weg so unterkommt.
+I’m **Demian**, a **Sysadmin**, **Email Infrastructure enthusiast**, and a passionate **Open Source contributor**. This is where I’ll be sharing what I know about system administration, managing email infrastructure, and contributing to open source projects.
 
-## Worum geht's hier?
+## What to Expect
 
-Auf diesem Blog findet ihr hoffentlich nützliches Zeug zu:
+On this blog, I’ll be writing about:
 
-- **Sysadmin-Kram**: Alles, was ich über Server, Netzwerke und Infrastruktur durch Trial & Error gelernt habe.
-- **E-Mail-Infrastruktur**: Weil E-Mail nun mal nicht totzukriegen ist und jemand sich darum kümmern muss.
-- **Open Source**: Wie ich dazu gekommen bin, mich zu beteiligen, und wie ihr das auch machen könnt.
+- **Sysadmin tips and tools**: Everything I’ve learned managing servers, networks, and infrastructure.
+- **Email Infrastructure**: Best practices for setting up, securing, and managing email systems.
+- **Open Source**: How I contribute to open source projects, and tips for getting started if you want to do the same.
 
-## Warum das Ganze?
+This blog is a space to share knowledge, troubleshoot common issues, and explore new tools and techniques. Whether you’re just getting into system administration, looking for email setup guides, or interested in contributing to open source, you’ll find something useful here.
 
-Ich bin seit ein paar Jahren in der IT unterwegs und habe dabei mehr Fehler gemacht, als mir lieb ist. Über die Sachen zu schreiben hilft mir, sie nicht nochmal zu machen – und vielleicht profitiert ja auch der ein oder andere davon. Ich bin ein großer Fan von **Learning by Doing**, und dieser Blog ist genau das: meine gesammelten Erfahrungen, Erfolge und Failures.
+## Why I’m Here
 
-Freut mich, dass ihr vorbeischaut. Wenn ihr Bock habt, lasst gern einen Kommentar da oder schreibt mir.
+I’ve been working in IT for a while now, and I’ve learned a lot by trial and error. Writing about my experiences helps me remember the lessons I’ve learned and hopefully helps others along the way. I believe in **learning by doing**, and this blog is just a reflection of that approach.
+
+I’m excited to share what I’ve picked up, and I hope you’ll find these posts useful, whether you’re a fellow sysadmin or just someone interested in these topics.
 
 ---
 
-Bis zum nächsten Post!
+## Let’s Connect
+
+Feel free to reach out. Thanks for stopping by, and I look forward to sharing more soon!
+

content/posts/spaceship-distrobox.md

@@ -1,32 +1,33 @@
 +++
 date = '2026-01-04T20:33:45+01:00'
 draft = false
-title = 'Spaceship Distrobox – Nie wieder die Übersicht verlieren'
+title = 'Spaceship Distrobox'
 
 [cover]
 image = "/imgs/spaceship.png"
-alt = "Offizielles Spaceship Rocket Logo"
+alt = "official spaceship rocket logo"
 caption = ""
 +++
 
-# In welcher Box bin ich grad nochmal?
+# How I Solved the Distrobox Confusion in My Terminal
 
-Letztens ist mir aufgefallen: Ich hab ständig mehrere Terminal-Fenster offen, und irgendwann weiß ich nicht mehr, welches davon in ner **Distrobox** läuft und welches auf meinem Host-System ist. Kennt ihr das? Ihr wechselt zwischen Projekten, öffnet hier mal schnell ein Terminal, da mal eins – und zack, ihr führt `apt install` im Host aus, obwohl ihr dachtet, ihr wärt in der Box.
+Recently, I found myself struggling with something that seemed like a simple problem: when I was working with multiple terminal windows, I could never remember which one was inside a Distrobox and which one was on my local system. If you've ever juggled between different environments, you know exactly how annoying this can get.
 
-Ja, mir ist das passiert. Mehrmals.
+So, I decided to create a quick plugin for my favorite terminal prompt, **Spaceship**, that would clearly indicate when I'm inside a Distrobox container. The result is a simple, customizable section that appears right in your prompt, showing the name of the active container. This way, I never have to guess or dig deeper to figure out where I'm working.
 
-Also hab ich mir überlegt: Ich brauch was, das mir SOFORT zeigt, ob ich in ner Distrobox bin. Ich nutze **Spaceship Prompt** und hab ein Plugin dafür geschrieben, das genau das macht. Einfach, schlank, und es knallt mir den Containernamen direkt ins Prompt.
+## Why This Plugin Exists
 
-## Warum gibt's das?
+While there are already tools and functions for **Bash** or even the **Starship Prompt** to detect and display if you're inside a container, I couldn't find anything that suited my needs for **Spaceship Prompt**. I wanted a minimal, easy to install plugin that would do exactly what I needed: show me when I'm in a Distrobox without cluttering up my prompt.
 
-Klar, für **Bash** oder **Starship Prompt** gibt's schon Tools, die anzeigen, ob man in nem Container steckt. Aber für **Spaceship Prompt** hab ich nix Passendes gefunden. Also hab ich's selbst gebaut.
+That's why I created this plugin. It's simple, lightweight, and specifically designed for Spaceship users who want to easily track which environment they're in without extra hassle.
 
-### Was das Ding kann:
+### Key Features:
 
-- **Sofort erkennbar**: Ich seh auf einen Blick, ob ich in ner Distrobox bin. Kein `echo $CONTAINER_ID` mehr.
-- **Anpassbar**: Symbol, Farbe und Position kann ich ändern. Passt sich an mein Setup an.
-- **Minimaler Aufwand**: Ich nutze Spaceship eh schon – das Plugin einzubauen hat mich keine 5 Minuten gekostet.
+- **Instant Visual Cue**: It's super clear when I'm inside a Distrobox. No need to check `CONTAINER_ID` or other variables.
+- **Customizable**: I can change the symbol, the color, and the position in the prompt to match my setup.
+- **Super Simple Setup**: I'm already using the Spaceship prompt, so adding this feature took just a couple of lines of code.
 
-### Wo gibt's das?
+### Where to get it
+
+For installation and configuration instructions, check out the [Spaceship Distrobox plugin Repository](https://github.com/pyte1/spaceship-distrobox).
 
-Installation und Konfiguration gibt's im [Spaceship Distrobox Plugin Repository](https://github.com/pyte1/spaceship-distrobox).