Problem
Stellenbörsen-Newsletter (StepStone, JobLeads, freelance.de, LinkedIn Job Alerts, XING etc.) verstopfen den Mail-Posteingang in einer Größenordnung, die kein Mensch mehr sinnvoll sichten kann.
Konkreter Beleg (28.04.2026)
In den letzten 9 Tagen sind 162 Jobmails eingelaufen. Das sind ~18 Mails/Tag. Jede dieser Mails enthält typisch 5–15 Stellenvorschläge → effektiv ~1000+ Stellen pro Woche, durch die der User durchgehen müsste.
Realität: Es schafft niemand. Folge:
- Relevante Stellen werden übersehen
- Nur das, was zufällig oben liegt, wird angeklickt
- Newsletter werden irgendwann pauschal als Spam markiert (siehe #524)
- PBP nutzt diese Datenquelle praktisch gar nicht
Vorschlag: Stellenbörsen-Newsletter automatisch in den Jobs-Pool ingestieren
Konzept
PBP liest Newsletter aus, extrahiert die einzelnen Stellen und speist sie in den vorhandenen jobs-Pool ein — dort werden sie über das vorhandene Scoring (#169) bewertet. Der User sieht nur das, was den Threshold übersteigt.
Workflow
Newsletter-Mail kommt in PBP rein
→ Sender-Domain erkannt (stepstone.de, jobleads.com, freelance.de, ...)
→ Newsletter-Parser extrahiert Stellen-Liste
→ Stellen werden in `jobs`-Tabelle eingefügt (mit Quelle = "stepstone_newsletter" etc.)
→ Scoring (#169) bewertet automatisch
→ Newsletter-Mail wird archiviert oder gelöscht
→ Im Dashboard: "Diese Woche kamen 1042 Stellen rein, 23 mit Score >70 — hier sind sie"
Wichtig: KEIN Auto-Match auf Bewerbungen
Newsletter-Stellen werden in den jobs-Pool eingespeist, NICHT als Bewerbungen angelegt. Erst wenn der User in der Liste eine Stelle aktiv anklickt und sagt "auf die bewerbe ich mich", wird daraus eine Bewerbung. Das schützt vor Müll-Bewerbungen.
Parser pro Newsletter-Quelle
Jede Stellenbörse hat ein anderes Format. Brauche dedizierte Parser:
| Quelle |
Format |
Schwierigkeit |
| StepStone Jobagent |
HTML mit konsistenter Struktur, manchmal JSON-LD |
Niedrig–Mittel |
JobLeads (<email-anonymisiert>) |
HTML-Tabellen |
Mittel |
| freelance.de |
HTML-Listen |
Mittel |
| LinkedIn Job Alerts |
Tracking-URLs verschleiert die echten Jobs |
Hoch |
| XING |
HTML, Tracking-Links |
Hoch |
→ Anfangen mit den 1–2 Quellen mit dem höchsten Volumen (vermutlich StepStone + JobLeads).
Deduplikation
Newsletter listen oft dieselben Stellen mehrfach (heute, morgen, übermorgen). Hash-basierte Dedup pro Stelle (Firma + Titel + Ort + URL) ist nötig — was vermutlich eh schon im jobs-Schema vorhanden ist (#317).
Anti-Müll-Logik
Newsletter sind oft Spam mit dünnem Cover — manche LinkedIn-Alerts schicken Stellen, die nichts mit den eigentlichen Suchkriterien zu tun haben. Daher:
Abgrenzung zu vorhandenen Issues
| Issue |
Bezug |
| #469 Thunderbird-Integration |
Liefert die Mail-Quelle, aber kein Newsletter-Parsing |
| #504 Plugin-Plattform v1.7 |
Newsletter-Parser könnte als Plugin auf der Ingest-API sitzen |
| #524 Spam-Lifeline |
Spam → INBOX zurückholen. Dieses Issue hier: was tun, wenn die INBOX schon voll ist |
| #169 Scoring-Konfiguration |
Liefert die Bewertung, die hier zur Filterung gebraucht wird |
| #317 Job-Hash / Duplikat-Erkennung |
Wahrscheinlich schon vorhanden — gut, dann brauchen wir's hier |
| #481 iCal-Sync |
Andere Quelle, gleicher Plugin-Pattern |
Vorhandenes Tool blacklist_verwalten |
Weiter nutzen für Domain/Firma-Filter |
Akzeptanzkriterien
Implementierungsoptionen
Option A: Direkt im PBP-Core (minimal viable)
Ein einfacher StepStone-Parser als erste Quelle, IMAP-basiert oder Drag-and-Drop wie bei #524.
Option B: Als Plugin auf #504-API
pbp-newsletter-ingest als Sub-Repo, ein Sub-Modul pro Quelle.
→ Vorschlag: Erst MVP mit StepStone in Option A (sofortiger Hebel), dann Migration auf Plugin-Architektur.
Nutzen-Abschätzung
Wenn 162 Jobmails in 9 Tagen eingehen mit je ~10 Stellen → ~1620 Stellen/9 Tage → ~180 Stellen/Tag. Bei einem Scoring-Threshold von 70 dürften realistisch 5–15 % "relevant" sein → 9–27 Stellen pro Tag, die der User wirklich bewerten will. Das ist eine Größenordnung, die handhabbar ist.
→ Faktisch bedeutet das: aus "ich kann nicht mehr sinnvoll durch Mails gehen" wird "ich schaue mir täglich ~15 Stellen an, die schon vorgefiltert sind".
Prioritaet
Hoch — der konkrete Pain ist heute schon da, nicht nur ein theoretisches Problem. Sollte zumindest in Form von Option A in v1.7 oder v1.8 mitlaufen.
Verwandt
Problem
Stellenbörsen-Newsletter (StepStone, JobLeads, freelance.de, LinkedIn Job Alerts, XING etc.) verstopfen den Mail-Posteingang in einer Größenordnung, die kein Mensch mehr sinnvoll sichten kann.
Konkreter Beleg (28.04.2026)
In den letzten 9 Tagen sind 162 Jobmails eingelaufen. Das sind ~18 Mails/Tag. Jede dieser Mails enthält typisch 5–15 Stellenvorschläge → effektiv ~1000+ Stellen pro Woche, durch die der User durchgehen müsste.
Realität: Es schafft niemand. Folge:
Vorschlag: Stellenbörsen-Newsletter automatisch in den Jobs-Pool ingestieren
Konzept
PBP liest Newsletter aus, extrahiert die einzelnen Stellen und speist sie in den vorhandenen
jobs-Pool ein — dort werden sie über das vorhandene Scoring (#169) bewertet. Der User sieht nur das, was den Threshold übersteigt.Workflow
Wichtig: KEIN Auto-Match auf Bewerbungen
Newsletter-Stellen werden in den
jobs-Pool eingespeist, NICHT als Bewerbungen angelegt. Erst wenn der User in der Liste eine Stelle aktiv anklickt und sagt "auf die bewerbe ich mich", wird daraus eine Bewerbung. Das schützt vor Müll-Bewerbungen.Parser pro Newsletter-Quelle
Jede Stellenbörse hat ein anderes Format. Brauche dedizierte Parser:
<email-anonymisiert>)→ Anfangen mit den 1–2 Quellen mit dem höchsten Volumen (vermutlich StepStone + JobLeads).
Deduplikation
Newsletter listen oft dieselben Stellen mehrfach (heute, morgen, übermorgen). Hash-basierte Dedup pro Stelle (Firma + Titel + Ort + URL) ist nötig — was vermutlich eh schon im jobs-Schema vorhanden ist (#317).
Anti-Müll-Logik
Newsletter sind oft Spam mit dünnem Cover — manche LinkedIn-Alerts schicken Stellen, die nichts mit den eigentlichen Suchkriterien zu tun haben. Daher:
blacklist_verwalten)suchkriterien_anzeigen) — wenn keine MUSS-Keywords im Stellentitel/-beschreibung, rausAbgrenzung zu vorhandenen Issues
blacklist_verwaltenAkzeptanzkriterien
jobs-Pool angelegt mit Quelle = "_newsletter"Implementierungsoptionen
Option A: Direkt im PBP-Core (minimal viable)
Ein einfacher StepStone-Parser als erste Quelle, IMAP-basiert oder Drag-and-Drop wie bei #524.
Option B: Als Plugin auf #504-API
pbp-newsletter-ingestals Sub-Repo, ein Sub-Modul pro Quelle.→ Vorschlag: Erst MVP mit StepStone in Option A (sofortiger Hebel), dann Migration auf Plugin-Architektur.
Nutzen-Abschätzung
Wenn 162 Jobmails in 9 Tagen eingehen mit je ~10 Stellen → ~1620 Stellen/9 Tage → ~180 Stellen/Tag. Bei einem Scoring-Threshold von 70 dürften realistisch 5–15 % "relevant" sein → 9–27 Stellen pro Tag, die der User wirklich bewerten will. Das ist eine Größenordnung, die handhabbar ist.
→ Faktisch bedeutet das: aus "ich kann nicht mehr sinnvoll durch Mails gehen" wird "ich schaue mir täglich ~15 Stellen an, die schon vorgefiltert sind".
Prioritaet
Hoch — der konkrete Pain ist heute schon da, nicht nur ein theoretisches Problem. Sollte zumindest in Form von Option A in v1.7 oder v1.8 mitlaufen.
Verwandt