Unerklärliche E-Mail::Empfänger::UngültigePost-Fehler

Fehler
1

Einige Mailinglisten sind unter Mailing Lists - Tor Project Forum gespiegelt.\n\nWir haben kürzlich festgestellt, dass einige Nachrichten nicht von der Mailman3-Mailingliste auf das Forum gespiegelt wurden.\n\nDie E-Mail-Ablehnungs-Logs zeigen, dass diese E-Mails auf einen Email::Receiver::InvalidPost-Fehler gestoßen sind.\n\nDie protokollierte Fehlermeldung lautet eine der beiden folgenden:\n\n> Es tut uns leid, aber Ihre E-Mail-Nachricht an \[„tor-relays@lists.torproject.org“\] (Titel \[tor-relays\] authority bandwidth measurements and latency) hat nicht funktioniert.\n>\n> Grund:\n>\n> Zugriff verweigert\n>\n> Wenn Sie das Problem beheben können, versuchen Sie es bitte erneut.\n\noder:\n\n> Es tut uns leid, aber Ihre E-Mail-Nachricht an \[„tor-relays@lists.torproject.org“\] (Titel \[tor-relays\] Re: webtunnel bridges for the telegram distributor) hat nicht funktioniert.\n>\n> Grund:\n>\n> Etwas ist schiefgelaufen. Vielleicht wurde dieses Thema geschlossen oder gelöscht, während Sie es betrachtet haben?\n>\n> Wenn Sie das Problem beheben können, versuchen Sie es bitte erneut.\n\nIch kann beim Betrachten der Header nichts Falsches an diesen Nachrichten finden, obwohl in einigen Fällen der extrahierte Body im Log nur den Mailinglisten-Footer enthält oder in einem anderen Fall eine Reihe von Kauderwelsch-Zeichen, als ob es eine Dekodierungsstörung gegeben hätte.\n\nIch habe versucht, dieses Problem mit einer Test-Mailingliste und einer Testkategorie zu reproduzieren, war aber erfolglos. Jede Hilfe bei der Fehlersuche wäre willkommen.

2

Ist „E-Mails von anonymen Konten akzeptieren“ in den Einstellungen jeder Kategorie aktiviert, und könnten Sie bitte das Discourse-E-Mail-Protokoll (leicht geschwärzt, wenn möglich) senden?

1 „Gefällt mir“
3

Ja, ich kann bestätigen, dass diese Einstellung aktiviert ist.

und könnten Sie bitte das Discourse-E-Mail-Protokoll (wenn möglich leicht geschwärzt) senden
Ist das etwas, das ich aus dem Container oder dem Host extrahieren muss? Wir verarbeiten E-Mails auch über den mail-receiver-Container. Oder möchten Sie die Protokolle, die in der Weboberfläche angezeigt werden (z. B. /admin/email-logs/rejected)?

4

Kam es von Exchange?

Manchmal sendet Microsoft Exchange Müll, wenn es falsch konfiguriert ist und denkt, es würde mit… Ich bin mir nicht sicher - einem anderen Exchange-Server? Etwas anderem innerhalb seiner eigenen Infrastruktur?

Sie können die rohe E-Mail von der Discourse-Konsole aus mit z. B. anzeigen:

mid = 'message-id from the log'
puts IncomingEmail.find_by(message_id: mid).raw

Dies zeigt die rohe E-Mail, die Discourse empfangen hat. Zum Beispiel ist der E-Mail-Text, den ich gerade aus unserer Liste eingehender Ablehnungen gezogen habe, wirklich Kauderwelsch:

This is a multi-part message in MIME format.
--=====003_Dragon855807841081_=====
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: base64

7bgir+m+vzzIDCLE0mDmZrfIXvvmXjY=

--=====003_Dragon855807841081_=====
Content-Type: text/html;
 charset=utf-8
Content-Transfer-Encoding: base64

LP/0L4tqmfZizO0DCDDE10uOzMZqzSHDjq04SLPaBjibLVHz+V94m1M45NDN
55aM8SMIf9XY4EFjP9CCFz+ojfmJqmubaz+bjrzmubw+bjWTiGSuLg==

--=====003_Dragon855807841081_=====--

da die Teile nicht in gültigen Text dekodiert werden.

2 „Gefällt mir“
5

beides wäre großartig. Wenn Sie PuTTy SSH verwenden, können Sie die Container-Logs extrahieren, und Sie könnten die Discourse-Benutzeroberfläche ausschneiden. Allerdings können Sie Wörter im Foto nicht einfach suchen, um sie zu schwärzen😮‍💨

6

Ich konnte zwei E-Mails mit den vollständigen Headern extrahieren. Ein MUA ist Apple Mail und der andere ist Claws Mail.

Ich würde diese gerne zur Fehlersuche an die private E-Mail-Adresse von jemandem weiterleiten, damit wir sie nicht überall im Internet veröffentlichen müssen.

Ich denke, in beiden Fällen ist es wahrscheinlich, dass Discourse den E-Mail-Inhalt nicht richtig parst.

7

Zur Information, dies ist immer noch ein Problem. Discourse verwirft regelmäßig E-Mail-Listen-Nachrichten von verschiedenen Absendern mit dem Fehler Email::Receiver::InvalidPost, aus Gründen, die ich nicht ermitteln kann.

8

Wenn Sie auf den Fehler in den Protokollen klicken, wird dann der Grund für den Zurückweisung angezeigt?

z. B.:

image
image970×332 11.6 KB

9

Wenn Sie auf den Fehler in den Protokollen klicken, wird dann im Bounce-Grund angegeben, warum?

Diese Nachrichten gibt es in zwei Varianten:

Es tut uns leid, aber Ihre E-Mail-Nachricht an [\"tor-relays@lists.torproject.org\"] (mit dem Titel [tor-relays] Re: abuse report from relays in family 7EAAC49A7840D33B62FA276429F3B03C92AA9327) hat nicht funktioniert.

Grund:

Etwas ist schiefgelaufen. Vielleicht wurde dieses Thema geschlossen oder gelöscht, während Sie es angesehen haben?

Wenn Sie das Problem beheben können, versuchen Sie es bitte erneut.

Ich kann bestätigen, dass in diesen Fällen nichts dergleichen (Thema geschlossen oder gelöscht) passiert ist.

Manchmal ist der Grund einfach Zugriff verweigert.

10

Hallo lavamind – entschuldige, dass ich einen alten Thread wiederbelebe, aber ich wollte mich zuerst erkundigen, bevor wir tiefer in die Fehlersuche einsteigen.

Treten die Email::Receiver::InvalidPost-Ablehnungen beim Spiegeln der Mailingliste aktuell (spätes 2025 / frühes 2026) immer noch auf?

Falls ja, könnten Sie eine kurze Momentaufnahme teilen von:

  • ungefähr wie oft es passiert (z. B. täglich/wöchentlich, % der Nachrichten)
  • ob der „Grund“ der abgelehnten E-Mail immer noch hauptsächlich „Zugriff verweigert“ im Vergleich zu „Thema geschlossen/gelöscht“ ist
  • ob es eine Liste/Kategorie oder mehrere betrifft

Sobald wir bestätigen, dass es weiterhin auftritt, können wir mit dem Sammeln des Mindestdatensatzes für einen einzelnen aktuellen Fehler fortfahren (Message-ID + die entsprechende gespeicherte Roh-E-Mail usw.).

11

Keine Entschuldigung nötig, ich freue mich sehr, dass Sie sich das ansehen.

Hallo lavamind – entschuldige, dass ich einen alten Thread wiederbelebe, aber ich wollte mich zuerst erkundigen, bevor wir tiefer in die Fehlersuche einsteigen.

Sehen Sie die Email::Receiver::InvalidPost-Ablehnungen beim Spiegeln der Mailingliste auch jetzt noch (Ende 2025 / Anfang 2026)?

Ja, das Problem tritt weiterhin auf.

Ungefähr wie oft tritt es auf (z. B. täglich/wöchentlich, % der Nachrichten)?

Die Häufigkeit ist schwer genau festzulegen, aber das Problem betrifft mindestens mehrere Nachrichten pro Woche, grob geschätzt vielleicht irgendwo zwischen 5 und 10 % der Nachrichten? Einige Absender scheinen in den Fehlerprotokollen überrepräsentiert zu sein, es sieht also zumindest nicht völlig zufällig aus.

Ob der „Grund“ der abgelehnten E-Mail immer noch hauptsächlich „Zugriff verweigert“ im Vergleich zu „Thema geschlossen/gelöscht“ ist

Es ist immer noch eine Mischung aus beidem.

Ob es eine Liste/Kategorie oder mehrere betrifft

Es betrifft hauptsächlich die Kategorie tor-relays, aber diese Liste erhält regelmäßigen Input von mehreren Absendern im Gegensatz zu den anderen Listen, die wir spiegeln und die viel weniger Traffic erhalten.

Sobald wir bestätigen, dass es weiterhin auftritt, können wir mit dem Sammeln des Mindestdatensatzes für einen einzelnen aktuellen Fehler fortfahren (Message-ID + die entsprechende gespeicherte Roh-E-Mail usw.).

Wir könnten uns diesen aktuellen Thread ansehen. Das Archiv von Mailman zeigt, dass es 5 Nachrichten empfangen hat, aber das Forum-Spiegel-Thema enthält nur 3 Beiträge. Die Ablehnungsprotokolle enthalten 3 InvalidPost-Fehler für dieses Thema (seltsamerweise 2 vom selben Absender), und bei allen lautet der angezeigte Ablehnungsgrund: „Etwas ist schiefgelaufen. Vielleicht wurde dieses Thema geschlossen oder gelöscht, während Sie es angesehen haben?“

12

Danke lavamind – das ist ein wirklich hilfreicher Datenpunkt, besonders weil wir einen konkreten Thread haben, an dem wir uns orientieren können: „Mailman-Archiv zeigt 5, Forenthema zeigt 3“.

Da Sie dies mehrmals pro Woche sehen (grob geschätzt 5–10 % der Nachrichten) und die Abprallursache bei diesem Vorfall durchweg die irreführende Variante „Thema geschlossen/gelöscht“ ist, besteht der nächste beste Schritt darin, eine fehlgeschlagene Nachricht Ende-zu-Ende zu erfassen, damit wir sehen können, was Discourse dachte, dass es tat.

Könnten Sie für eine der 3 abgewiesenen E-Mails, die mit diesem Spiegelthema verbunden sind, Folgendes abrufen:

  1. Öffnen Sie unter /admin/email-logs/rejected eine der Zeilen InvalidPost für diesen Vorfall und kopieren Sie:

    • die Message-ID
    • das Datum/die Uhrzeit
    • die in der Zeile angezeigten (redigierten) An/Von/Betreff
    • den vollständigen Abprallgrundtext (wie angezeigt)

  2. Extrahieren Sie aus der Rails-Konsole (im Discourse-App-Container) die Roh-E-Mail, die Discourse gespeichert hat:

@supermathie ist IncomingEmail immer noch der kanonische Ort, um die Rohdaten abzurufen, und gibt es noch etwas anderes, das Sie für das Debugging von InvalidPost zusätzlich benötigen würden?

mid = "<Fügen Sie hier die Message-ID aus dem Protokoll der abgewiesenen E-Mail ein>"
ie  = IncomingEmail.find_by(message_id: mid)

puts ie&.raw
  1. Rufen Sie außerdem die zugehörigen EmailLog-Attribute für dieselbe Message-ID ab (dies zeigt oft, ob Discourse sie als Antwort oder als neues Thema behandelt hat und welche Themen-/Kategorie-IDs es aufgelöst hat):
mid = "<dieselbe Message-ID wie oben>"

log = EmailLog.where(message_id: mid).order(created_at: :desc).first
pp log&.attributes&.slice(
  "id",
  "email_type",
  "to_address",
  "from_address",
  "subject",
  "post_id",
  "topic_id",
  "user_id",
  "status",
  "bounce_error_code",
  "bounce_key",
  "created_at"
)

Warum dieses Trio?

  • IncomingEmail.raw verrät uns, ob die E-Mail fehlerhaft / seltsam kodiert / nur mit Fußzeile angekommen ist, im Gegensatz dazu, dass Discourse den „falschen“ MIME-Teil ausgewählt hat.
  • EmailLog teilt uns mit, was Discourse versucht hat (neues Thema vs. Antwort, aufgelöste Themen-/Kategorie-IDs usw.).
  • Die UI-Zeile der abgewiesenen E-Mail bestätigt, dass wir denselben Vorfall betrachten, und bewahrt, was die Betreiber sehen.

Wenn Datenschutz Bedenken bereitet, können Sie Adressen und jeglichen Nachrichtentext innerhalb von raw redigieren, aber bitte behalten Sie bei:

  • MIME-Header (Content-Type, Begrenzungen, Zeichensatz, Content-Transfer-Encoding)
  • die Multipart-Struktur (damit wir sehen können, welche Teile vorhanden sind)
  • die Message-ID und grundlegende Routing-Header (Sie können Domänen bei Bedarf redigieren)

Sobald wir eine fehlschlagende Message-ID + IncomingEmail.raw + den EmailLog-Ausschnitt haben, sollten wir schnell feststellen können, ob es sich um Folgendes handelt:

  • eine Diskrepanz bei Antwortschlüsseln/Themen-Routing,
  • einen Berechtigungs-Grenzfall,
  • oder ein Fehler beim E-Mail-Parsing / der MIME-Teilauswahl / der Dekodierung.
13

Vielen Dank für die sehr detaillierte Anleitung!

Konzentrieren wir uns auf diese Nachricht, die an das Mailinglisten-Thema gesendet wurde.

Die Header des Vorfallprotokolls der abgelehnten Nachricht zeigen Folgendes:

Message-ID: <20260103080033.5f6d8f90@dorfdsl.de>
Date: Sat, 03 Jan 2026 08:00:33 +0100
From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
To: tor-relays@lists.torproject.org
Subject: [tor-relays] Re: Questions about running an exit relay

Der vollständige Ablehnungsgrund lautet wie folgt:

We're sorry, but your email message to ["tor-relays@lists.torproject.org"] (titled [tor-relays] Re: Questions about running an exit relay) didn't work.

Reason:

Something has gone wrong. Perhaps this topic was closed or deleted while you were looking at it?

If you can correct the problem, please try again.

Der Klartext-Eintrag der E-Mail, die von Mailman an Discourse gesendet wurde (IncomingEmail), ist hier verfügbar (ich glaube nicht, dass er Daten enthält, die nicht bereits öffentlich sind, aber ich habe den Link trotzdem so eingestellt, dass er irgendwann abläuft).

Leider konnten meine Versuche, das EmailLog zu extrahieren, kein Ergebnis liefern: Es scheint, dass Discourse keinen solchen Eintrag für diese Nachricht hat.

14

Danke @lavamind – das ist ausgezeichnet (Message-ID + Ablehnungstext + eine Kopie dessen, was Discourse gespeichert hat).

Außerdem: Entschuldigung meinerseits wegen der Anfrage nach EmailLog – es ist sehr plausibel (und vielleicht sogar erwartet), dass es keinen EmailLog-Eintrag für eine solche eingehende Ablehnung gibt. EmailLog ist hauptsächlich für ausgehende E-Mails gedacht, während eingehende E-Mails in IncomingEmail leben (was Sie bereits abgerufen haben). @supermathie kannst du bestätigen, dass ich hier niemanden auf den falschen Weg schicke?

Da wir ja den IncomingEmail-Eintrag haben, könntest du bitte die Metadatenfelder aus demselben Datensatz einfügen? Das sollte uns den Kontext liefern, den ich mir von EmailLog erhofft hatte, nämlich „Was hat Discourse versucht zu tun?“.

In der Rails-Konsole:

# @supermathie Abgleich: Sind für das Debugging eingehender ungültiger Beiträge die Metadaten von IncomingEmail das richtige nächste Element, das gesammelt werden sollte?
mid = "<20260103080033.5f6d8f90@dorfdsl.de>"
ie  = IncomingEmail.find_by(message_id: mid)

pp ie&.attributes&.slice(
  "id",
  "message_id",
  "from_address",
  "to_addresses",
  "cc_addresses",
  "subject",
  "created_at",
  "user_id",
  "post_id",
  "topic_id",
  "error"
)

# optional: falls du dich damit wohlfühlst, ist dies oft auch nützlich
# (es zeigt, was Discourse als Body extrahiert hat vs. was es roh gespeichert hat)
pp ie&.attributes&.slice("raw", "cooked")

(Wenn raw/cooked sehr groß sind, kannst du sie gerne weglassen – du hast das Rohe bereits geteilt.)

Warum diese Felder wichtig sind:

  • topic_id / post_id (falls vorhanden) verraten uns, ob Discourse dies als Antwort/neuen Beitrag aufgelöst hat und was das Ziel war.
  • user_id verrät uns, welchem temporären/echten Benutzer Discourse den Absender zugeordnet hat (Berechtigungs- oder „Zugriff verweigert“-Fälle).
  • error ist oft spezifischer als der generische „Thema geschlossen/gelöscht“-Abpralltext.

Wenn diese Attribute eine Auflösung zu topic_id/post_id zeigen, die auf das Spiegelthema verweist, dann ist der wahrscheinliche nächste Schritt herauszufinden, warum der Empfänger es als ungültig eingestuft hat (leerer extrahierter Body, MIME-Dekodierung, Berechtigungsinkongruenz, Reply-Key-Inkongruenz usw.). Wenn es überhaupt keine Themen-/Beitragsauflösung zeigt, konzentrieren wir uns auf Routing-Header / Antwort-Erkennung.

Und nochmals – danke für das Einfügen des Links. Eine einzige, konkrete fehlschlagende Message-ID wie diese ist genau das, was wir brauchten, um mit dem Raten aufzuhören.

15

Ja, das ist richtig. Und ich stimme zu – es wird zeigen, was empfangen wurde, welche Zuordnungen Discourse vornehmen konnte, und hoffentlich den nächsten Schritt anzeigen.

1 „Gefällt mir“
16

Hier sind die Metadatenfelder für das IncomingObject

{"id"=>9785,
"message_id"=>"20260103080033.5f6d8f90@dorfdsl.de",
"from_address"=>"mm@dorfdsl.de",
"to_addresses"=>"tor-relays@lists.torproject.org",
"cc_addresses"=>"",
"subject"=>"[tor-relays] Re: Questions about running an exit relay",
"created_at"=>2026-01-03 07:03:04.639775000 UTC +00:00,
"user_id"=>10477,
"post_id"=>nil,
"topic_id"=>nil,
"error"=>"Email::Receiver::InvalidPost"}

Was den Roh-/gekochten Inhalt betrifft, enthält nur die raw-Eigenschaft die vollständige E-Mail mit Headern. Die cooked-Eigenschaft existiert in dem Objekt nicht.

17

Wenn man das durch Email::Receiver.new(rawmessage).select_body laufen lässt, erhält man:

=> ["", "", 2]

Daher bin ich ziemlich sicher, dass hier das passiert, dass Discourse fälschlicherweise einen leeren Text-/Plain-Teil als Nachrichtentext auswählt, wahrscheinlich diesen hier:

--Sig_/gizYC_1dGsAzUHvksdaMIe2
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

was ein ungültiger Beitrag wäre.

Wir müssen das etwas untersuchen und es wahrscheinlich als Testfall verwenden.

18

Die E-Mail hat die folgende Struktur:

* #<Mail::Part:39500, Multipart: false, Headers: <MIME-Version: 1.0>, <Content-Type: text/plain; charset=us-ascii>, <Content-Transfer-Encoding: 7bit>, <Content-Disposition: inline>, <Content-ID: <6958bf289b75c_b28a46298091029@forum-01-app.mail>>>
  "___…tor-relays mailing list…"
* #<Mail::Part:39520, Multipart: true, Headers: <Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2"; micalg=pgp-sha256; protocol="application/pgp-signature">, <Content-Transfer-Encoding: 7bit>>
  * #<Mail::Part:39540, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>,
    "On 02.01.2026…"
  * #<Mail::Part:39560, Multipart: false, Headers: <Content-Type: text/plain; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>>,
    ""
  * #<Mail::Part:39580, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>,
    "On 02.01.2026…"
  * #<Mail::Part:39600, Multipart: false, Headers: <Content-Type: text/plain; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>>,
    ""
  * #<Mail::Part:39620, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>,
    "On 02.01.2026…"
  * #<Mail::Part:39640, Multipart: false, Headers: <Content-Type: text/plain; charset=UTF-8>, <Content-Transfer-Encoding: 7bit>>,
    ""
  * #<Mail::Part:39660, Multipart: false, Headers: <Content-Type: text/plain; charset=US-ASCII>, <Content-Transfer-Encoding: quoted-printable>>,
    "On 02.01.2026…"
  * #<Mail::Part:39680, Multipart: false, Headers: <Content-Type: application/pgp-signature>, <Content-Description: Digitale Signatur von OpenPGP>>>,
    PGP signature
  * #<Mail::Part:39700, Multipart: false, Headers: <Content-Type: application/pgp-signature>, <Content-Transfer-Encoding: 7bit>, <Content-Description: Digitale Signatur von OpenPGP>>>,
    PGP signature
  * #<Mail::Part:39720, Multipart: false, Headers: <Content-Type: application/pgp-signature>, <Content-Transfer-Encoding: 7bit>, <Content-Description: Digitale Signatur von OpenPGP>>>
    PGP signature

(ja, es gibt drei Kopien des eigentlichen Inhalts, des leeren Inhalts und der PGP-Signatur)

Dieser erste text/plain-Teil wird von der Mailinglisten-Software hinzugefügt und sieht so aus:

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

Das ist es, was Discourse (eigentlich das Mail-Gem über .text_part) als Inhalt der Nachricht auswählt:

> puts mail.text_part.to_s
MIME-Version: 1.0
Content-Type: text/plain;
 charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-ID: <6958bf289b75c_b28a46298091029@forum-01-app.mail>

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

und als leerer Body mit einer ausgelassenen Signatur behandelt wird.

Wäre dieser größtenteils leere Teil, der von der Mailingliste hinzugefügt wurde, nicht vorhanden, hätte Discourse den folgenden Inhalt für den Beitrag extrahiert:

> We received a court order to preserve the data on the system and were
> forbidden from informing the system owner, which was awkward since
> they had informed the system owner...

Welche Daten wurden angefordert?

> Since then I've always run my exit on a separate system on it's own
> IP so if there were a legal demand to turn over "the system" it would
> really only be that system. I'm not a lawyer but I don't think docker
> provides enough isolation for that.

Können sie Ihnen verbieten, den Relay auszuschalten?
Wenn ja, könnten Sie dann einen neuen "System" auf einer anderen IP betreiben.

(ausgelassener Teil unten)

On 02.01.2026 18:46 Jon via tor-relays <tor-relays@lists.torproject.org> wrote:

-- 
kind regards
Marco

Send spam to abfall1767375998@stinkedores.dorfdsl.de

Ich kann hier eigentlich keinen Fehler in der Mail-Verarbeitung von Discourse finden – wenn ich Schuld zuweisen müsste, würde ich wahrscheinlich bei der Mailinglisten-Software anfangen, weil sie effektiv leeren Inhalt am Anfang hinzufügt. Dieser wäre besser am Ende platziert, nach der eigentlichen Nachricht.

Es hätte mit dem Mail-Gem funktioniert und würde auch in Mail-Clients besser aussehen – hier ist es in Thunderbird, wie ursprünglich empfangen:

image
image856×765 106 KB

und meine “korrigierte” Version (test-fixed.eml.txt (14,3 KB))
mit der Mailinglisten-Signatur am Ende statt am Anfang:

image
image864×773 106 KB

20

Ich habe einen (menschlichen) Abonnenten dieser Liste kontaktiert, und so sieht der reine Nachrichtentext in seinem MUA aus, wobei einige Header herausgefiltert wurden:

Subject: [tor-relays] Re: Questions about running an exit relay
List-Id: "support and questions about running Tor relays (exit, non-exit,
 bridge)" <tor-relays.lists.torproject.org>
Archived-At: 
 <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
List-Archive: 
 <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
List-Help: <mailto:tor-relays-request@lists.torproject.org?subject=help>
List-Owner: <mailto:tor-relays-owner@lists.torproject.org>
List-Post: <mailto:tor-relays@lists.torproject.org>
List-Subscribe: <mailto:tor-relays-join@lists.torproject.org>
List-Unsubscribe: <mailto:tor-relays-leave@lists.torproject.org>
From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
Reply-To: Marco Moock <mm@dorfdsl.de>
Content-Type: multipart/mixed; boundary="===============8958541500975114832=="

--===============8958541500975114832==
Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2";
 protocol="application/pgp-signature"; micalg=pgp-sha256

--Sig_/gizYC_1dGsAzUHvksdaMIe2
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On 02.01.2026 18:46 Jon via tor-relays
 <tor-relays@lists.torproject.org> wrote:

 > We received a court order to preserve the data on the system and were
 > forbidden from informing the system owner, which was awkward since
 > they had informed the system owner...

Which data did they request?

 > Since then I've always run my exit on a separate system on it's own
 > IP so if there were a legal demand to turn over "the system" it would
 > really only be that system. I'm not a lawyer but I don't think docker
 > provides enough isolation for that.

Can they deny you to turn the relay off?
If so, you could then operate a new "system" on another IP.

--=20
kind regards
Marco

Send spam to abfall1767375998@stinkedores.dorfdsl.de

--Sig_/gizYC_1dGsAzUHvksdaMIe2
Content-Type: application/pgp-signature
Content-Description: Digitale Signatur von OpenPGP

-----BEGIN PGP SIGNATURE-----
iQJPBAEBCAA5FiEEpXefSZn9R6zNZtTQE76RLz2tRfAFAmlYvpEbFIAAAAAABAAO
bWFudTIsMi41KzEuMTEsMiwyAAoJEBO+kS89rUXw8kgP/2jkrwfSWHY6EY4WJjn6
EDEqT00pgpwEn9ZpUqLTreS3/ocfHC4g29HIsxpJcj/bH+hNAx96HEz9YmC4JfEt
LDjYc6D+5NBBFQGy0vaJ/LXLQc63CRE/yySSOYxFBZK+uMytNHoZDTjhfRroICbQ
guoO7A4/VuYrGAzCWQkBUmnBjj2LJhuLDW84ObMXhA/EuNy5FIAqyLZxoGmFEfvu
We5d0Hr3+wihzyrgGiG4u8UGFOyL+/PC11CFQyQ0j03cBzhZ5PVdtkqPNHauAcjQ
Gt/HQmaOSGKq0VODRjiHAe5TuRtV6jOfUNgS1Q2vB4FKYmeDQb82ooNfOiJWy3ey
Jpwgg700ppqgZUclpMPlzxKwi2dT/PSO6yYuy+G5sfa0Hxmn5DsQaiSPMTiEP2WC
NwAENYIuHeQOHWiS8B3oVSRW/naLzkmpfChFnTKGsrhLqKQc/iuvv639aHwg9BP7
YEbWbdpFpIU36czfxoTcDYDR1e4JLWryEFKIgo4TIaz4t17NmkxjXB6dHZKLLAdU
AT6LmL6mOTaXe9ewD9pf9Vf2nG0RGVJyZRUDmFzfU0Rx2qi7KdcmmRpZg/2QtJeA
Pmrv8NFuFEL0BrhTvo7C60m+gjLaXPNClgKEN0vkEzjLp/ZKjI9FslP61xUMg8lQ
3xT/HTkNt9uNH2ziBMXLK+5c
=0Euf
-----END PGP SIGNATURE-----

--Sig_/gizYC_1dGsAzUHvksdaMIe2--

--===============8958541500975114832==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
tor-relays mailing list -- tor-relays@lists.torproject.org
To unsubscribe send an email to tor-relays-leave@lists.torproject.org

--===============8958541500975114832==--

Es gibt keine Duplizierung, und die Teile sind korrekt geordnet. Ich würde erwarten, dass dies eher dem entspricht, was Mailman tatsächlich an Listenabonnenten sendet. Andernfalls würden wir vielleicht etwas hören, wenn die meisten Leute Nachrichten mit dem Footer oben erhalten würden?

Ich frage mich dann, ob etwas anderes in der Verarbeitungspipeline die Nachrichtennutzlast durcheinander bringt. Unser Discourse-Server verarbeitet eingehende E-Mails zuerst mit Postfix, das so konfiguriert ist, dass es sie an einen mail-receiver Container übergibt, der sie dann an den Discourse-Container übergibt.

21

Oh! Angesichts dessen bin ich zurückgegangen und habe erneut untersucht … und es stellt sich heraus, dass es doch unser Problem ist.

Aus der oben geposteten Roh-E-Mail habe ich gerade entdeckt, dass IncomingEmail.raw die Roh-E-Mail nicht tatsächlich speichert … wir bereinigen sie zuerst mit Email::Cleaner.

Das scheint die Schuld des Ruby-Mail-Gems zu sein … es ordnet Teile einer Mail-Nachricht neu an, wenn es sie zurückschreibt:

[1] pry(main)> m = File.open('test.eml').read;
[2] pry(main)> Mail.new(m).parts
=> [
  #<Mail::Part:39680, Multipart: true, Headers: <Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2"; protocol="application/pgp-signature"; micalg=pgp-sha256>>,
  #<Mail::Part:39700, Multipart: false, Headers: <MIME-Version: 1.0>, <Content-Type: text/plain; charset="us-ascii">, <Content-Transfer-Encoding: 7bit>, <Content-Disposition: inline>>
]
[3] pry(main)> Mail.new(Mail.new(m).to_s).parts
=> [
  #<Mail::Part:39720, Multipart: false, Headers: <MIME-Version: 1.0>, <Content-Type: text/plain; charset=us-ascii>, <Content-Transfer-Encoding: 7bit>, <Content-Disposition: inline>, <Content-ID: <6966b4914df79_31d5b1d38126@mars.mail>>>,
  #<Mail::Part:39740, Multipart: true, Headers: <Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2"; micalg=pgp-sha256; protocol="application/pgp-signature">, <Content-Transfer-Encoding: 7bit>>
]

was das Problem verursacht:

[38] pry(main)> puts Email::Receiver.new(m).select_body[0];
=> We received a court order to preserve the data on the system and were
=> forbidden from informing the system owner, which was awkward since
=> they had informed the system owner...

Which data did they request?

=> Since then I've always run my exit on a separate system on it's own
=> IP so if there were a legal demand to turn over "the system" it would
=> really only be that system. I'm not a lawyer but I don't think docker
=> provides enough isolation for that.

Can they deny you to turn the relay off?
If so, you could then operate a new "system" on another IP.

[39] pry(main)> puts Email::Receiver.new(Mail.new(m).to_s).select_body[0];
«no output»
Unterschiedsdetails

test.eml: Rohnachricht wie bereitgestellt
test-rubyparsed.eml: Nachricht von Ruby geparst und dann wieder in einen String umgewandelt
test-pythonparsed.eml: Nachricht von Python geparst und dann wieder in einen String umgewandelt

--- test.eml	2026-01-13 15:58:18.769489410 -0500
+++ test-rubyparsed.eml	2026-01-13 16:11:17.767312268 -0500
@@ -1,25 +1,46 @@
+Date: Tue, 13 Jan 2026 16:07:21 -0500
+From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
+Reply-To: Marco Moock <mm@dorfdsl.de>
+Message-ID: <6966b40914be8_31d5b1d38719@mars.mail>
 Subject: [tor-relays] Re: Questions about running an exit relay
+MIME-Version: 1.0
+Content-Type: multipart/mixed;
+ boundary="===============8958541500975114832=="
+Content-Transfer-Encoding: 7bit
 List-Id: "support and questions about running Tor relays (exit, non-exit,
  bridge)" <tor-relays.lists.torproject.org>
-Archived-At: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
-List-Archive: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
+Archived-At: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
+List-Archive: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
 List-Help: <mailto:tor-relays-request@lists.torproject.org?subject=help>
 List-Owner: <mailto:tor-relays-owner@lists.torproject.org>
 List-Post: <mailto:tor-relays@lists.torproject.org>
 List-Subscribe: <mailto:tor-relays-join@lists.torproject.org>
 List-Unsubscribe: <mailto:tor-relays-leave@lists.torproject.org>
-From: Marco Moock via tor-relays <tor-relays@lists.torproject.org>
-Reply-To: Marco Moock <mm@dorfdsl.de>
-Content-Type: multipart/mixed; boundary="===============8958541500975114832=="
+
+
+--===============8958541500975114832==
+MIME-Version: 1.0
+Content-Type: text/plain;
+ charset=us-ascii
+Content-Transfer-Encoding: 7bit
+Content-Disposition: inline
+Content-ID: <6966b40914ae9_31d5b1d38641@mars.mail>
+
+_______________________________________________
+tor-relays mailing list -- tor-relays@lists.torproject.org
+To unsubscribe send an email to tor-relays-leave@lists.torproject.org
  
 --===============8958541500975114832==
-Content-Type: multipart/signed; boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2";
- protocol="application/pgp-signature"; micalg=pgp-sha256
+Content-Type: multipart/signed;
+ boundary="Sig_/gizYC_1dGsAzUHvksdaMIe2";
+ micalg=pgp-sha256;
+ protocol="application/pgp-signature"
+Content-Transfer-Encoding: 7bit
+ 
 --Sig_/gizYC_1dGsAzUHvksdaMIe2
-Content-Type: text/plain; charset=US-ASCII
+Content-Type: text/plain;
+ charset=US-ASCII
 Content-Transfer-Encoding: quoted-printable
  
 On 02.01.2026 18:46 Jon via tor-relays
@@ -39,7 +60,8 @@
 Can they deny you to turn the relay off?
 If so, you could then operate a new "system" on another IP.
 
---=20
+-- =
+
 kind regards
 Marco
  
@@ -47,14 +69,15 @@
 --Sig_/gizYC_1dGsAzUHvksdaMIe2
 Content-Type: application/pgp-signature
+Content-Transfer-Encoding: 7bit
 Content-Description: Digitale Signatur von OpenPGP
  
 -----BEGIN PGP SIGNATURE-----
@@ -69,14 +92,5 @@
 
 --Sig_/gizYC_1dGsAzUHvksdaMIe2--
 
---===============8958541500975114832==
-Content-Type: text/plain; charset="us-ascii"
-MIME-Version: 1.0
-Content-Transfer-Encoding: 7bit
-Content-Disposition: inline
-
-_______________________________________________
-tor-relays mailing list -- tor-relays@lists.torproject.org
-To unsubscribe send an email to tor-relays-leave@lists.torproject.org
-
+--===============8958541500975114832==
+

--- test.eml	2026-01-13 15:58:18.769489410 -0500
+++ test-pythonparsed.eml	2026-01-13 16:19:30.385608544 -0500
@@ -1,10 +1,8 @@
 Subject: [tor-relays] Re: Questions about running an exit relay
 List-Id: "support and questions about running Tor relays (exit, non-exit,
  bridge)" <tor-relays.lists.torproject.org>
-Archived-At: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
-List-Archive: 
- <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
+Archived-At: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/message/OAX7EO72GLXS4KPKUG7QSG7EOAR2WYVA/>
+List-Archive: <https://lists.torproject.org/mailman3/hyperkitty/list/tor-relays@lists.torproject.org/>
 List-Help: <mailto:tor-relays-request@lists.torproject.org?subject=help>
 List-Owner: <mailto:tor-relays-owner@lists.torproject.org>
 List-Post: <mailto:tor-relays@lists.torproject.org>
3 „Gefällt mir“