Beim Versand der Serien-Email wird im Protokoll zwar angezeigt, dass der Versand erfolgreich war, aber beim Empfänger kommt keine Email an (Bestätigt bei Verfahren Nr18-Fr. Ritter- michaela.ritter@radeburg.de, auch im Spam kein Eintrag), Nur 1 Email von 7 ist nachweislich angekommen.
Beim Versand der Serien-Email wird im Protokoll zwar angezeigt, dass der Versand erfolgreich war, aber beim Empfänger kommt keine Email an (Bestätigt bei Verfahren Nr18-Fr. Ritter- michaela.ritter@radeburg.de, auch im Spam kein Eintrag), Nur 1 Email von 7 ist nachweislich angekommen.
Daniel
added the Bug label 2026-06-18 08:47:30 +00:00
Die Diagnose hat gezeigt: Alle 7 Mails sind aus dem VLN-System sauber rausgegangen (Spooler-Status SENT, vom Smarthost mit Queue-ID angenommen). Das Nicht-Ankommen lag nicht am Beteiligungs-Feature, sondern an fehlender E-Mail-Authentifizierung der Absender-Domain → strenge Provider (t-online, aol, vodafone, freenet, radeburg.de) haben verworfen/spam-gefiltert.
Umgesetzt:
DMARC-Record veröffentlicht (p=none, Monitoring)
DKIM domain-alignt aktiv (netcup, Selektor key2, d=flurneuordnung-sachsen.de)
@Erik / @Daniel: Bitte Verfahren 18 erneut versenden an die Empfänger, die nichts erhalten haben – jetzt sollte die Zustellung klappen. Gebt kurz Rückmeldung, ob die Mails ankommen, dann schließe ich das Issue.
Optionale Folgeschritte (nicht zwingend): SPF von ~all auf -all straffen, DMARC nach Monitoring auf quarantine/reject hochziehen, List-Unsubscribe-Header für Serien-Mails ergänzen.
**Ursache gefunden & behoben.**
Die Diagnose hat gezeigt: Alle 7 Mails sind aus dem VLN-System sauber rausgegangen (Spooler-Status SENT, vom Smarthost mit Queue-ID angenommen). Das Nicht-Ankommen lag **nicht** am Beteiligungs-Feature, sondern an fehlender **E-Mail-Authentifizierung** der Absender-Domain → strenge Provider (t-online, aol, vodafone, freenet, radeburg.de) haben verworfen/spam-gefiltert.
**Umgesetzt:**
- **DMARC**-Record veröffentlicht (`p=none`, Monitoring)
- **DKIM** domain-alignt aktiv (netcup, Selektor `key2`, `d=flurneuordnung-sachsen.de`)
- **SPF** bestätigt `pass`
**Nachweis:** mail-tester.com → **10/10**, `dkim=pass` (aligned, header.d=flurneuordnung-sachsen.de), `spf=pass`, `dmarc=pass`, in keiner Blocklist.
@Erik / @Daniel: Bitte **Verfahren 18 erneut versenden** an die Empfänger, die nichts erhalten haben – jetzt sollte die Zustellung klappen. Gebt kurz Rückmeldung, ob die Mails ankommen, dann schließe ich das Issue.
_Optionale Folgeschritte (nicht zwingend): SPF von `~all` auf `-all` straffen, DMARC nach Monitoring auf `quarantine`/`reject` hochziehen, List-Unsubscribe-Header für Serien-Mails ergänzen._
Bei erneuter Beteiligung (Verfahren #810) ist der Emailversand wieder unvollständig. mind. 2 Adressen (innius-doe.de, googlemail.com, freenet.de) haben auch beim erneuten Versuch keine Mail erhalten, andere Emails waren erfolgreich. Spamfilter und Adresse gemeinsam mit Adressaten überprüft.
Bei erneuter Beteiligung (Verfahren #810) ist der Emailversand wieder unvollständig. mind. 2 Adressen (innius-doe.de, googlemail.com, freenet.de) haben auch beim erneuten Versuch keine Mail erhalten, andere Emails waren erfolgreich. Spamfilter und Adresse gemeinsam mit Adressaten überprüft.
Ursache gefunden — die Mails haben unser Haus nie verlassen. Und der Fehler saß dieses Mal woanders als im Juni.
Was wirklich passiert ist. Es gab zwei Versandläufe für Verfahren #810, nicht einen:
Lauf
Empfänger
Stand in der Warteschlange
27.08. 13:24 „Umlaufbeschluss 1.Änderung Wege- und Gewässerplan"
alle 7
zugestellt an den Mailserver (Zeilen 1768–1774)
08.09. 15:02 „Bitte um Stellungnahme: Umlaufbeschluss …"
alle 7
fehlgeschlagen (1781–1787), nie versendet
Beim zweiten Lauf ist keine einzige Mail hinausgegangen — auch nicht die, von denen wir „erfolgreich" angenommen haben. Erfolgreich waren die Mails vom 27.08. Die ausgehende Verbindung zum Mailserver trug am 08.09. von 15:03 bis 15:09 nicht; in diesen sechs Minuten hat jede Mail ihre drei erlaubten Versuche verbraucht und lag danach endgültig auf Fehler. Gemeldet wurde das niemandem.
Drei Fehler, alle behoben (PR VLN_SN/wwwpy#592, seit heute im Betrieb):
Die Fehlermeldung war falsch. In der Datenbank stand als Grund [Errno 101] Network is unreachable. Das war der IPv6-Versuch, für den es im Container gar keinen Weg gibt — Python meldet bei mehreren Adressen nur den letzten Fehler und hat damit den echten IPv4-Grund verdeckt. Der Verbindungsaufbau geht jetzt nur über IPv4 und nennt im Fehler jede Adresse mit ihrem eigenen Grund.
Mails starben nach einer Viertelstunde. Statt drei Versuchen im 5-Minuten-Abstand sind es jetzt sechs mit 5/15/60/180/360 Minuten — eine Störung von einem halben Arbeitstag überlebt der Versand damit. Bleibt eine Mail trotzdem liegen, gibt es automatisch eine Fehlermeldung ins System (bisher: nichts). Zusätzlich gibt es ein Prüfskript, das den Weg testet, ohne eine Mail zu verschicken.
Das Protokoll hat gelogen. „7 E-Mail(s) erfolgreich gesendet" hieß in Wahrheit „7 in die Warteschlange eingereiht" — den Versand macht ein Dienst danach. Ab jetzt steht in der Empfängerliste je Zeile der wirkliche Stand: übergeben / in Warteschlange / fehlgeschlagen, und bei Fehlern gibt es einen Knopf zum erneuten Einreihen. Das Protokoll-PDF sagt „eingereiht" statt „gesendet".
Wichtig zur Wortwahl: „übergeben" heißt nur, dass unser Mailserver die Nachricht angenommen hat. Ob sie im Postfach landet, entscheidet der Anbieter des Empfängers — das können wir von hier aus nicht sehen.
@Daniel — was zu tun ist: Die sieben Mails vom 08.09. bitte nicht erneut einreihen, sondern neu versenden: im Text steht als Frist der 10.09.2026, die ist heute abgelaufen. Also Anschreiben mit neuer Frist, Versand starten, und anschließend in der Empfängerliste in der Spalte Mail nachsehen — dort steht dann für jeden Empfänger, was passiert ist. Wenn eine Zeile auf „fehlgeschlagen" steht, bitte hier melden, dann sehen wir den Grund direkt.
Eine Frage bleibt offen und betrifft den Lauf vom 27.08.: die Mails wurden von unserem Mailserver angenommen, drei Empfänger (innius-doe.de, googlemail.com, freenet.de) haben sie laut Rückmeldung trotzdem nicht bekommen. Das lässt sich nur an den Rückläufern („Bounces") im Postfach noreply@flurneuordnung-sachsen.de beim Anbieter klären. SPF, DKIM und DMARC stehen weiterhin korrekt (heute geprüft), es ist also nicht der Rückfall des Juni-Problems. @Erik: Zugang zu diesem Postfach vorhanden?
**Ursache gefunden — die Mails haben unser Haus nie verlassen.** Und der Fehler saß dieses Mal woanders als im Juni.
**Was wirklich passiert ist.** Es gab zwei Versandläufe für Verfahren #810, nicht einen:
| Lauf | Empfänger | Stand in der Warteschlange |
|---|---|---|
| 27.08. 13:24 „Umlaufbeschluss 1.Änderung Wege- und Gewässerplan" | alle 7 | **zugestellt an den Mailserver** (Zeilen 1768–1774) |
| **08.09. 15:02 „Bitte um Stellungnahme: Umlaufbeschluss …"** | alle 7 | **fehlgeschlagen** (1781–1787), nie versendet |
Beim zweiten Lauf ist **keine einzige** Mail hinausgegangen — auch nicht die, von denen wir „erfolgreich" angenommen haben. Erfolgreich waren die Mails vom 27.08. Die ausgehende Verbindung zum Mailserver trug am 08.09. von 15:03 bis 15:09 nicht; in diesen sechs Minuten hat jede Mail ihre drei erlaubten Versuche verbraucht und lag danach endgültig auf Fehler. Gemeldet wurde das niemandem.
**Drei Fehler, alle behoben** (PR VLN_SN/wwwpy#592, seit heute im Betrieb):
1. **Die Fehlermeldung war falsch.** In der Datenbank stand als Grund `[Errno 101] Network is unreachable`. Das war der IPv6-Versuch, für den es im Container gar keinen Weg gibt — Python meldet bei mehreren Adressen nur den letzten Fehler und hat damit den echten IPv4-Grund verdeckt. Der Verbindungsaufbau geht jetzt nur über IPv4 und nennt im Fehler jede Adresse mit ihrem eigenen Grund.
2. **Mails starben nach einer Viertelstunde.** Statt drei Versuchen im 5-Minuten-Abstand sind es jetzt sechs mit 5/15/60/180/360 Minuten — eine Störung von einem halben Arbeitstag überlebt der Versand damit. Bleibt eine Mail trotzdem liegen, gibt es automatisch eine Fehlermeldung ins System (bisher: nichts). Zusätzlich gibt es ein Prüfskript, das den Weg testet, ohne eine Mail zu verschicken.
3. **Das Protokoll hat gelogen.** „7 E-Mail(s) erfolgreich gesendet" hieß in Wahrheit „7 in die Warteschlange eingereiht" — den Versand macht ein Dienst danach. Ab jetzt steht in der Empfängerliste je Zeile der wirkliche Stand: **übergeben / in Warteschlange / fehlgeschlagen**, und bei Fehlern gibt es einen Knopf zum erneuten Einreihen. Das Protokoll-PDF sagt „eingereiht" statt „gesendet".
Wichtig zur Wortwahl: **„übergeben" heißt nur, dass unser Mailserver die Nachricht angenommen hat.** Ob sie im Postfach landet, entscheidet der Anbieter des Empfängers — das können wir von hier aus nicht sehen.
**@Daniel — was zu tun ist:** Die sieben Mails vom 08.09. bitte **nicht** erneut einreihen, sondern **neu versenden**: im Text steht als Frist der 10.09.2026, die ist heute abgelaufen. Also Anschreiben mit neuer Frist, Versand starten, und anschließend in der Empfängerliste in der Spalte *Mail* nachsehen — dort steht dann für jeden Empfänger, was passiert ist. Wenn eine Zeile auf „fehlgeschlagen" steht, bitte hier melden, dann sehen wir den Grund direkt.
**Eine Frage bleibt offen** und betrifft den Lauf vom 27.08.: die Mails wurden von unserem Mailserver angenommen, drei Empfänger (innius-doe.de, googlemail.com, freenet.de) haben sie laut Rückmeldung trotzdem nicht bekommen. Das lässt sich nur an den Rückläufern („Bounces") im Postfach `noreply@flurneuordnung-sachsen.de` beim Anbieter klären. SPF, DKIM und DMARC stehen weiterhin korrekt (heute geprüft), es ist also nicht der Rückfall des Juni-Problems. @Erik: Zugang zu diesem Postfach vorhanden?
Nachtrag — der Test-Versand von heute ist vollständig heraus.
@Daniel, der Lauf „Flurbereinigung Berbisdorf- E-Mail-Test." von heute 10:09 Uhr ist bei allen 8 von 8 Empfängern aus unserem System heraus und vom Mailserver angenommen worden (10:10–10:11 Uhr, kein Fehlversuch). Das ist zugleich der erste Lauf mit der neuen Anzeige: in der Empfängerliste steht jetzt in der Spalte Mail je Zeile übergeben, und die Karte oben zählt „8 an Mailserver übergeben".
Damit ist der Weg aus dem Haus belegt. Wenn ein Empfänger trotzdem nichts findet, liegt es hinter unserer Grenze (Spamfilter oder Ablehnung beim Anbieter) — dann bitte hier melden mit Adresse und Uhrzeit, dann sehen wir uns die Rückläufer an.
Für den eigentlichen Vorgang gilt weiter: der Lauf vom 08.09. ist tot und die dort genannte Frist (10.09.) ist abgelaufen. Das Anschreiben bitte mit neuer Frist verschicken, nicht die alten Mails erneut einreihen.
**Nachtrag — der Test-Versand von heute ist vollständig heraus.**
@Daniel, der Lauf „Flurbereinigung Berbisdorf- E-Mail-Test." von heute 10:09 Uhr ist bei allen **8 von 8** Empfängern aus unserem System heraus und vom Mailserver angenommen worden (10:10–10:11 Uhr, kein Fehlversuch). Das ist zugleich der erste Lauf mit der neuen Anzeige: in der Empfängerliste steht jetzt in der Spalte *Mail* je Zeile **übergeben**, und die Karte oben zählt „8 an Mailserver übergeben".
Damit ist der Weg aus dem Haus belegt. Wenn ein Empfänger trotzdem nichts findet, liegt es hinter unserer Grenze (Spamfilter oder Ablehnung beim Anbieter) — dann bitte hier melden mit Adresse und Uhrzeit, dann sehen wir uns die Rückläufer an.
Für den eigentlichen Vorgang gilt weiter: der Lauf vom 08.09. ist tot und die dort genannte Frist (10.09.) ist abgelaufen. Das Anschreiben bitte mit **neuer Frist** verschicken, nicht die alten Mails erneut einreihen.
ich habe 4 Rückläufer, unter anderem von den Adressen, die vorher keine Mail empfangen haben. Ich gehe davon aus, dass der Rest einfach seine Emails nicht liest. Es scheint also zu funktionieren.
Da die PDF zur Dokumentation des Versands, die jetzt automatisch nach dem Klick auf "Serien-Email senden" erzeugt wird, mit dem neuen Vorgehen immer nur "eingereiht" zeigt: Bitte Protokoll-Button im Email-Versandbereich des Bearbeitungs-Tabs einfügen, über den der Nutzer das Protokoll anlegen kann, wenn alle Emails als versandt markiert sind.
ich habe 4 Rückläufer, unter anderem von den Adressen, die vorher keine Mail empfangen haben. Ich gehe davon aus, dass der Rest einfach seine Emails nicht liest. Es scheint also zu funktionieren.
Da die PDF zur Dokumentation des Versands, die jetzt automatisch nach dem Klick auf "Serien-Email senden" erzeugt wird, mit dem neuen Vorgehen immer nur "eingereiht" zeigt: Bitte Protokoll-Button im Email-Versandbereich des Bearbeitungs-Tabs einfügen, über den der Nutzer das Protokoll anlegen kann, wenn alle Emails als versandt markiert sind.
Der gewünschte Protokoll-Knopf ist da – seit heute Abend live.
Im Bearbeiten-Bereich steht im Abschnitt E-Mail-Versand neben „Serien-E-Mail vorbereiten“ jetzt der Knopf „Versandprotokoll (PDF)“ (sobald einmal versendet wurde). Er erzeugt das Protokoll mit dem Stand, den die Seite gerade zeigt: je Empfänger, ob die Mail an den Mailserver übergeben wurde, noch in der Warteschlange steht oder fehlgeschlagen ist, dazu eine Zusammenfassung und ob geantwortet wurde. Am besten erst drücken, wenn alle Mails als „übergeben“ angezeigt werden.
Das PDF direkt beim Absenden gibt es weiterhin; es kann naturgemäß nur „eingereiht“ zeigen.
@Daniel Bitte nach dem nächsten Versand einmal das Protokoll über den neuen Knopf erzeugen und prüfen. Wenn alles passt, kann die Meldung geschlossen werden.
Der gewünschte Protokoll-Knopf ist da – seit heute Abend live.
Im Bearbeiten-Bereich steht im Abschnitt E-Mail-Versand neben „Serien-E-Mail vorbereiten“ jetzt der Knopf **„Versandprotokoll (PDF)“** (sobald einmal versendet wurde). Er erzeugt das Protokoll mit dem Stand, den die Seite gerade zeigt: je Empfänger, ob die Mail an den Mailserver übergeben wurde, noch in der Warteschlange steht oder fehlgeschlagen ist, dazu eine Zusammenfassung und ob geantwortet wurde. Am besten erst drücken, wenn alle Mails als „übergeben“ angezeigt werden.
Das PDF direkt beim Absenden gibt es weiterhin; es kann naturgemäß nur „eingereiht“ zeigen.
@Daniel Bitte nach dem nächsten Versand einmal das Protokoll über den neuen Knopf erzeugen und prüfen. Wenn alles passt, kann die Meldung geschlossen werden.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Beim Versand der Serien-Email wird im Protokoll zwar angezeigt, dass der Versand erfolgreich war, aber beim Empfänger kommt keine Email an (Bestätigt bei Verfahren Nr18-Fr. Ritter- michaela.ritter@radeburg.de, auch im Spam kein Eintrag), Nur 1 Email von 7 ist nachweislich angekommen.
@KAI prüfe beim 0_beteiligung mit der ID 18 ob die entsprechenden Mails über den Mailspooler gegangen sind und wie der zustand der mails dort ist
wird erledigt
Ursache gefunden & behoben.
Die Diagnose hat gezeigt: Alle 7 Mails sind aus dem VLN-System sauber rausgegangen (Spooler-Status SENT, vom Smarthost mit Queue-ID angenommen). Das Nicht-Ankommen lag nicht am Beteiligungs-Feature, sondern an fehlender E-Mail-Authentifizierung der Absender-Domain → strenge Provider (t-online, aol, vodafone, freenet, radeburg.de) haben verworfen/spam-gefiltert.
Umgesetzt:
p=none, Monitoring)key2,d=flurneuordnung-sachsen.de)passNachweis: mail-tester.com → 10/10,
dkim=pass(aligned, header.d=flurneuordnung-sachsen.de),spf=pass,dmarc=pass, in keiner Blocklist.@Erik / @Daniel: Bitte Verfahren 18 erneut versenden an die Empfänger, die nichts erhalten haben – jetzt sollte die Zustellung klappen. Gebt kurz Rückmeldung, ob die Mails ankommen, dann schließe ich das Issue.
Optionale Folgeschritte (nicht zwingend): SPF von
~allauf-allstraffen, DMARC nach Monitoring aufquarantine/rejecthochziehen, List-Unsubscribe-Header für Serien-Mails ergänzen.Bei erneuter Beteiligung (Verfahren #810) ist der Emailversand wieder unvollständig. mind. 2 Adressen (innius-doe.de, googlemail.com, freenet.de) haben auch beim erneuten Versuch keine Mail erhalten, andere Emails waren erfolgreich. Spamfilter und Adresse gemeinsam mit Adressaten überprüft.
Ursache gefunden — die Mails haben unser Haus nie verlassen. Und der Fehler saß dieses Mal woanders als im Juni.
Was wirklich passiert ist. Es gab zwei Versandläufe für Verfahren #810, nicht einen:
Beim zweiten Lauf ist keine einzige Mail hinausgegangen — auch nicht die, von denen wir „erfolgreich" angenommen haben. Erfolgreich waren die Mails vom 27.08. Die ausgehende Verbindung zum Mailserver trug am 08.09. von 15:03 bis 15:09 nicht; in diesen sechs Minuten hat jede Mail ihre drei erlaubten Versuche verbraucht und lag danach endgültig auf Fehler. Gemeldet wurde das niemandem.
Drei Fehler, alle behoben (PR VLN_SN/wwwpy#592, seit heute im Betrieb):
[Errno 101] Network is unreachable. Das war der IPv6-Versuch, für den es im Container gar keinen Weg gibt — Python meldet bei mehreren Adressen nur den letzten Fehler und hat damit den echten IPv4-Grund verdeckt. Der Verbindungsaufbau geht jetzt nur über IPv4 und nennt im Fehler jede Adresse mit ihrem eigenen Grund.Wichtig zur Wortwahl: „übergeben" heißt nur, dass unser Mailserver die Nachricht angenommen hat. Ob sie im Postfach landet, entscheidet der Anbieter des Empfängers — das können wir von hier aus nicht sehen.
@Daniel — was zu tun ist: Die sieben Mails vom 08.09. bitte nicht erneut einreihen, sondern neu versenden: im Text steht als Frist der 10.09.2026, die ist heute abgelaufen. Also Anschreiben mit neuer Frist, Versand starten, und anschließend in der Empfängerliste in der Spalte Mail nachsehen — dort steht dann für jeden Empfänger, was passiert ist. Wenn eine Zeile auf „fehlgeschlagen" steht, bitte hier melden, dann sehen wir den Grund direkt.
Eine Frage bleibt offen und betrifft den Lauf vom 27.08.: die Mails wurden von unserem Mailserver angenommen, drei Empfänger (innius-doe.de, googlemail.com, freenet.de) haben sie laut Rückmeldung trotzdem nicht bekommen. Das lässt sich nur an den Rückläufern („Bounces") im Postfach
noreply@flurneuordnung-sachsen.debeim Anbieter klären. SPF, DKIM und DMARC stehen weiterhin korrekt (heute geprüft), es ist also nicht der Rückfall des Juni-Problems. @Erik: Zugang zu diesem Postfach vorhanden?Nachtrag — der Test-Versand von heute ist vollständig heraus.
@Daniel, der Lauf „Flurbereinigung Berbisdorf- E-Mail-Test." von heute 10:09 Uhr ist bei allen 8 von 8 Empfängern aus unserem System heraus und vom Mailserver angenommen worden (10:10–10:11 Uhr, kein Fehlversuch). Das ist zugleich der erste Lauf mit der neuen Anzeige: in der Empfängerliste steht jetzt in der Spalte Mail je Zeile übergeben, und die Karte oben zählt „8 an Mailserver übergeben".
Damit ist der Weg aus dem Haus belegt. Wenn ein Empfänger trotzdem nichts findet, liegt es hinter unserer Grenze (Spamfilter oder Ablehnung beim Anbieter) — dann bitte hier melden mit Adresse und Uhrzeit, dann sehen wir uns die Rückläufer an.
Für den eigentlichen Vorgang gilt weiter: der Lauf vom 08.09. ist tot und die dort genannte Frist (10.09.) ist abgelaufen. Das Anschreiben bitte mit neuer Frist verschicken, nicht die alten Mails erneut einreihen.
ich habe 4 Rückläufer, unter anderem von den Adressen, die vorher keine Mail empfangen haben. Ich gehe davon aus, dass der Rest einfach seine Emails nicht liest. Es scheint also zu funktionieren.
Da die PDF zur Dokumentation des Versands, die jetzt automatisch nach dem Klick auf "Serien-Email senden" erzeugt wird, mit dem neuen Vorgehen immer nur "eingereiht" zeigt: Bitte Protokoll-Button im Email-Versandbereich des Bearbeitungs-Tabs einfügen, über den der Nutzer das Protokoll anlegen kann, wenn alle Emails als versandt markiert sind.
Der gewünschte Protokoll-Knopf ist da – seit heute Abend live.
Im Bearbeiten-Bereich steht im Abschnitt E-Mail-Versand neben „Serien-E-Mail vorbereiten“ jetzt der Knopf „Versandprotokoll (PDF)“ (sobald einmal versendet wurde). Er erzeugt das Protokoll mit dem Stand, den die Seite gerade zeigt: je Empfänger, ob die Mail an den Mailserver übergeben wurde, noch in der Warteschlange steht oder fehlgeschlagen ist, dazu eine Zusammenfassung und ob geantwortet wurde. Am besten erst drücken, wenn alle Mails als „übergeben“ angezeigt werden.
Das PDF direkt beim Absenden gibt es weiterhin; es kann naturgemäß nur „eingereiht“ zeigen.
@Daniel Bitte nach dem nächsten Versand einmal das Protokoll über den neuen Knopf erzeugen und prüfen. Wenn alles passt, kann die Meldung geschlossen werden.