Translate all posts to German with personal blog style

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

@@ -1,126 +1,98 @@
 +++
 date = '2025-08-01T10:03:15+02:00'
 draft = false
-title = 'Blocking Invalid Recipients Before They Reach Your Exchange Server'
-
+title = 'Backscatter ade: Ungültige Empfänger vor dem Exchange abfangen'
 
 [cover]
 image = "/imgs/email-route.jpg"
-alt = "Email App icon on blue background"
+alt = "E-Mail App Icon auf blauem Hintergrund"
 caption = ""
 +++
 
-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.  
+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.
 
-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.
+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.
 
+## 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**.
 
-## What Even Is Backscatter?
+Passiert so:
 
-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**.
+- 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.
 
-It happens when:
+Und Zack, dein Server versendet Spam, ohne es zu wollen. Willkommen im Club.
 
-- 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.
+## Das Problem bei uns
 
-This makes your server appear to be sending spam, even though you're just bouncing bad mail.
+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.
 
+**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
 
-## The Problem in Our Setup
+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.
 
-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.  
+Dann kriegt der Sender sofort einen Korb und wir müssen erst gar keinen Bounce generieren. Win-Win.
 
-**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
+## Mögliche Lösungen (und warum ich sie verworfen hab)
 
 ### **1. relay_recipient_maps**
-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.  
+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.
 
-For us, this was too much custom scripting, too fragile, and too messy to maintain.
+Für uns war das zu viel Gefrickel, zu fehleranfällig und zu nervig zu warten.
 
+### **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.
 
-### **2. virtual_mailbox_maps with LDAP**
-Another approach would be using **LDAP lookups** directly against Active Directory to verify recipients in real-time.  
+Also auch gestrichen.
 
-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.
+## Die Lösung: `reject_unverified_recipient`
 
-So I ruled it out.
+Beim Durchlesen der **Postfix Address Verification Howto** bin ich über `reject_unverified_recipient` gestolpert – und dachte sofort: "Digga, genau das brauch ich!"
 
+### **Wie es funktioniert**
 
+Wenn ne eingehende SMTP-Session die `RCPT TO`-Phase erreicht:
 
-## 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:
+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:
      ```
      550 5.1.1 <user@example.de>: Recipient address rejected: User unknown
      ```
 
-Because the rejection happens **during SMTP**, no bounce is generated, and backscatter is avoided entirely.
+Weil die Ablehnung **während des SMTP-Dialogs** passiert, wird gar kein Bounce generiert. Backscatter ade!
 
+## Umsetzung in ISPConfig
 
-## Implementation 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.
 
-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.
+### Validation Server für die Empfängerprüfung
 
-### Specifying a Validation Server for Recipient Verification
+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`.
 
-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`.
+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.
 
-Make sure to restrict access to this port, as it requires anonymous login specifically for recipient validation, you don't want that exposed broadly.
+> **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.
 
-> **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.
+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.
 
-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.
+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.
 
-Now, for domains that need recipient verification, we can enable it in the panel and point Postfix to the appropriate **validation transport**.
+## Das Ergebnis
 
+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.
 
-## 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.
+## Fazit
 
+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,73 +1,76 @@
 +++
 date = '2025-05-18T11:34:09+02:00'
 draft = false
-title = 'Dovecot Index Cache Issues'
+title = 'Wenn der Dovecot-Index durchknallt'
 
 [cover]
 image = "/imgs/dove.jpg"
-alt = "Bunch of Doves on a roof"
-caption = ""
+alt = "Tauben auf nem Dach"
+caption = "Die Tauben auf dem Bild haben übrigens nix mit Dovecot zu tun. Fand ich nur passend."
 
 +++
 
-# Understanding `dovecot.index.cache`
+# 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:
 
-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. 
 
-# What Are `dovecot.index.cache` Files?
+Ü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.
 
-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.
+## Was Sind `dovecot.index.cache`-Dateien Überhaupt?
 
-Over time, the `dovecot.index.cache` file can grow very large or become outdated. Here are a few reasons why this happens:
+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.
 
-### During Normal Operation
+Mit der Zeit kann die `dovecot.index.cache` allerdings fett werden oder aus der Spur laufen. Hier ein paar Gründe:
 
-- 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.
+### Im Normalbetrieb
 
-### After a Migration
+- 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.
 
-Migrations are particularly prone to creating out-of-sync or bloated index files because:
+### Nach ner Migration
 
-- **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.
+Migrationen sind besonders fies, weil:
 
-# How to Deal with These Files
+- **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.
 
-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.
+## Wie Werd Ich Die Dinger Los?
 
-## Is It Safe to Delete These Files?
+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.
 
-Short answer: **Yes** — it's safe to delete all `dovecot.index*` files inside a user's Maildir.
+### Kann Ich Die Einfach 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.
+Kurze Antwort: **Ja** – du kannst alle `dovecot.index*`-Dateien im Maildir eines Benutzers löschen.
 
-## How to Find and Clean Up Large Index Files
+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:
 
-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 {} \;
 ```
-After validating these files and users, I then moved into the user’s Maildir and removed the files:
-```
+
+Nachdem ich die Kandidaten identifiziert hatte, bin ich ins Maildir des Users und hab die Dinger plattgemacht:
+
+```bash
 cd /var/vmail/domain.tld/affecteduser/Maildir/
 rm dovecot.index*
 ```
-## What Else Can I Do?
 
-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. 
+### Gibt's Auch Ne Sanftere Methode?
 
-Another option to prevent future bloat of these files would be adjusting the `mail_cache_fields` and `mail_never_cache_fields` in the configuration.
+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.
 
-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.
+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.
 
-# 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.
+## Fazit
 
+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,47 +1,44 @@
 +++
 date = '2025-10-10T09:26:56+02:00'
 draft = false
-title = 'Google Groups Spam'
+title = 'Google Groups Spam – Wenn Google zum Spam-Schleuder wird'
 
 [cover]
 image = "/imgs/google-spam.jpg"
-alt = "Google in bright colors and dark background"
+alt = "Google in bunten Farben auf dunklem Hintergrund"
 caption = ""
 +++
 
-# Understanding the Google Groups Spam Problem
+# Dieses Google Groups Problem nervt
 
-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.
+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.
 
-## Why it Happens
+## Warum passiert das?
 
-There are a few fundamental problems with how Google Groups works that make it particularly attractive to spammers:
+Google Groups hat ein paar grundlegende Design-Probleme, die es für Spammer besonders attraktiv machen:
 
-- **No opt-in required**: Spammers can freely add any email address to a Google Group without the recipient's consent.
+- **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.
 
-- **Unsubscribing is often impossible**: Many spam groups are set to private, meaning that victims cannot even access the group page to unsubscribe.
+## Das Problem und mein Ansatz
 
-- **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.
+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.
 
-## The Challenge and Approach
+Also hab ich mir was überlegt: Eine Lösung, die direkt in **Rspamd**, unserem Spam-Filter, eingreift:
 
-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.
+- **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.
 
-To handle this more effectively, I developed a solution that integrates directly with Rspamd, our spam filtering system:
+So zielen wir gezielt auf die missbräuchlichen Muster ab, ohne legitime Google-Groups-Nutzung zu bestrafen.
 
-- **Custom Lua plugin**: Detects messages originating from Google Groups and assigns a custom symbol.
+## Ran an die Tasten
 
-- **Composite rules**: Use this symbol, combined with other spam indicators, to decide whether a message should be classified as spam.
+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.
 
-This approach allows us to target the abusive patterns specifically, without penalizing legitimate use of Google Groups.
+### Schritt 1: Das Lua-Plugin bauen
 
-## 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`:
+Ab nach `/etc/rspamd/plugins.d/kits_header_google_group.lua`:
 
 ```lua
 rspamd_config:register_symbol{
@@ -66,51 +63,50 @@ rspamd_config:register_symbol{
 }
 ```
 
-This plugin checks for either of the following headers:
+Das Plugin sucht nach:
 
-- `X-Google-Group-Id`
-- `List-Unsubscribe` containing the string `googlegroups`
+- `X-Google-Group-Id` Header
+- `List-Unsubscribe` Header mit `googlegroups` drin
 
-If either is present, the message is tagged with the symbol `KITS_HEADER_GOOGLE_GROUP`.
+Wenn einer der beiden gefunden wird, gibt's das Symbol `KITS_HEADER_GOOGLE_GROUP`.
 
-### Step 2: Enable the Plugin
+### Schritt 2: Plugin aktivieren
 
-Next, register a module with the same name by creating an empty configuration file at `/etc/rspamd/modules.d/kits_header_google_group.conf`:
+Dann noch ein leeres Config-File anlegen unter `/etc/rspamd/modules.d/kits_header_google_group.conf`:
 
 ```bash
-# Empty config to enable lua plugin
+# Leere Config, um das Lua-Plugin zu aktivieren
 kits_header_google_group { }
 ```
 
-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.
+Ab jetzt wird jede Mail aus Google Groups mit `KITS_HEADER_GOOGLE_GROUP` getaggt und bekommt 'nen Score von 0,1.
 
-### Step 3: Create Composite Rules
+### Schritt 3: Composite Rules bauen
 
-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`:
+Jetzt die Composite Rules definieren. Ab damit nach `/etc/rspamd/override.d/composite.conf`:
 
 ```bash
-# Google Group origin with bulk or freemail origin
+# Google Group Ursprung mit Bulk oder Freemail
 KITS_GOOGLE_GROUP_BAD {
   expression = "KITS_HEADER_GOOGLE_GROUP and (DCC_REJECT | FUZZY_BULK | FREEMAIL_FROM)";
   score = 8.0;
 }
 
-# Google Group origin with bulk and freemail origin
+# Google Group Ursprung mit Bulk und Freemail
 KITS_GOOGLE_GROUP_WORST {
   expression = "KITS_HEADER_GOOGLE_GROUP and (DCC_REJECT | FUZZY_BULK ) and FREEMAIL_FROM";
   score = 20.0;
 }
 ```
 
-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 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`.
 
-> 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.
+> Die Namen, Scores und Logik sind auf meine Umgebung zugeschnitten. Passt die Werte immer an euer Setup an und testet vorher!
 
-## Conclusion
+## Fazit
 
-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.
+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.
 
-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.
+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.
 
+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,32 +1,27 @@
 +++
 date = '2025-05-11T20:13:49+02:00'
 draft = false
-title = 'Introduction'
+title = 'Hallo Welt!'
 +++
 
-# Welcome to My Blog!
+# Hallo und Herzlich Willkommen!
 
-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.
+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.
 
-## What to Expect
+## Worum geht's hier?
 
-On this blog, I’ll be writing about:
+Auf diesem Blog findet ihr hoffentlich nützliches Zeug zu:
 
-- **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.
+- **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.
 
-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.
+## Warum das Ganze?
 
-## Why I’m 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.
 
-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.
+Freut mich, dass ihr vorbeischaut. Wenn ihr Bock habt, lasst gern einen Kommentar da oder schreibt mir.
 
 ---
 
-## Let’s Connect
-
-Feel free to reach out. Thanks for stopping by, and I look forward to sharing more soon!
-
+Bis zum nächsten Post!

content/posts/spaceship-distrobox.md

@@ -1,33 +1,32 @@
 +++
 date = '2026-01-04T20:33:45+01:00'
 draft = false
-title = 'Spaceship Distrobox'
+title = 'Spaceship Distrobox – Nie wieder die Übersicht verlieren'
 
 [cover]
 image = "/imgs/spaceship.png"
-alt = "official spaceship rocket logo"
+alt = "Offizielles Spaceship Rocket Logo"
 caption = ""
 +++
 
-# How I Solved the Distrobox Confusion in My Terminal
+# In welcher Box bin ich grad nochmal?
 
-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.
+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.
 
-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.
+Ja, mir ist das passiert. Mehrmals.
 
-## Why This Plugin Exists
+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.
 
-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.
+## Warum gibt's das?
 
-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.
+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.
 
-### Key Features:
+### Was das Ding kann:
 
-- **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.
+- **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.
 
-### Where to get it
-
-For installation and configuration instructions, check out the [Spaceship Distrobox plugin Repository](https://github.com/pyte1/spaceship-distrobox).
+### Wo gibt's das?
 
+Installation und Konfiguration gibt's im [Spaceship Distrobox Plugin Repository](https://github.com/pyte1/spaceship-distrobox).