Errori Email non spiegati::Receiver::InvalidPost

Abbiamo alcune mailing list specchiate su Mailing Lists - Tor Project Forum

Recentemente abbiamo notato che alcuni messaggi non venivano specchiati dalla mailing list Mailman3 al forum.

I log di rifiuto delle email mostrano che queste email hanno riscontrato un errore Email::Receiver::InvalidPost.

Il messaggio di errore registrato è uno dei due seguenti:

Ci dispiace, ma il tuo messaggio email a [“tor-relays@lists.torproject.org”] (intitolato [tor-relays] misurazioni della larghezza di banda dell’autorità e latenza) non ha funzionato.

Motivo:

Accesso negato

Se riesci a correggere il problema, riprova.

o:

Ci dispiace, ma il tuo messaggio email a [“tor-relays@lists.torproject.org”] (intitolato [tor-relays] Re: ponti webtunnel per il distributore di telegrammi) non ha funzionato.

Motivo:

Qualcosa è andato storto. Forse questo argomento è stato chiuso o eliminato mentre lo stavi guardando?

Se riesci a correggere il problema, riprova.

Non riesco a trovare nulla di sbagliato in questi messaggi esaminando gli header, anche se in alcuni casi, il corpo estratto come registrato contiene solo il piè di pagina della mailing list, o in un altro caso, è un mucchio di caratteri senza senso come se ci fosse stato un problema di decodifica.

Ho provato a riprodurre questo problema utilizzando una mailing list di test e una categoria di test ma non ci sono riuscito. Qualsiasi aiuto per il debug sarebbe apprezzato.

è abilitata l’opzione “accetta email da account anonimi” nelle impostazioni di ogni categoria, e potresti inviare il log delle email di Discourse (leggermente modificato se possibile)

1 Mi Piace

Sì, posso confermare che questa impostazione è abilitata.

e potresti per favore inviare il log delle email di Discourse (leggermente modificato se possibile)
Si tratta di qualcosa che devo estrarre dal container o dall’host? Elaboriamo anche la posta tramite il container mail-receiver. Oppure desideri i log esposti nell’interfaccia Web (ad esempio, /admin/email-logs/rejected)?

È arrivata da Exchange?

A volte Microsoft Exchange invia dati spazzatura se è configurato erroneamente per pensare che stia parlando con… non sono sicuro - un altro server Exchange? Qualcos’altro all’interno della propria infrastruttura?

Puoi esaminare l’email grezza dalla console di Discourse con, ad esempio:

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

Questo mostra l’email grezza che Discourse ha ricevuto. Ad esempio, il corpo di questo messaggio che ho appena estratto dalla nostra lista di rifiuto in arrivo è davvero spazzatura:

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_=====--

poiché le parti non vengono decodificate in testo valido.

2 Mi Piace

entrambi sarebbero grandiosi. Se usi PuTTy SSH puoi estrarre i log del container e potresti ritagliare l’interfaccia utente di Discourse. Non puoi cercare facilmente parole nella foto, per redigerle😮‍💨

Sono riuscito a estrarre due email con gli header completi. Un MUA è Apple Mail e l’altro è Claws Mail.

Sarei felice di inoltrarle all’email privata di qualcuno per il debug, così eviteremo di incollarle ovunque su Internet.

Penso che in entrambi i casi sia probabile che Discourse non stia analizzando correttamente il contenuto dell’email.

Per la cronaca, questo è ancora un problema. Discourse elimina regolarmente i messaggi delle mailing list da vari mittenti con l’errore Email::Receiver::InvalidPost, per ragioni che non riesco a capire.

Se fai clic sull’errore nei log, viene visualizzato il motivo nel motivo del rimbalzo?

ad esempio:

Se fai clic sull’errore nei log, viene visualizzato il motivo nel motivo del rimbalzo?

Questi messaggi si presentano in due varianti:

Siamo spiacenti, ma il tuo messaggio di posta elettronica a ["tor-relays@lists.torproject.org"] (intitolato [tor-relays] Re: abuse report from relays in family 7EAAC49A7840D33B62FA276429F3B03C92AA9327) non ha funzionato.

Motivo:

Qualcosa è andato storto. Forse questo argomento è stato chiuso o eliminato mentre lo stavi guardando?

Se riesci a correggere il problema, riprova.

Posso confermare che non è accaduto nulla di simile (argomento chiuso o eliminato) in questi casi.

Altre volte, il Motivo è semplicemente Accesso negato.

Ciao lavamind - scusa per aver ripreso una vecchia discussione, ma volevo prima verificare prima di approfondire il debug.

Stai ancora riscontrando i rifiuti Email::Receiver::InvalidPost sul mirroring delle mailing list al momento (fine 2025 / inizio 2026)?

In caso affermativo, potresti condividere una rapida panoramica di:

  • con quale frequenza si verifica (ad esempio, giornalmente / settimanalmente, % dei messaggi)
  • se la “Ragione” dell’email rifiutata è ancora principalmente “Accesso Negato” rispetto a “argomento chiuso/eliminato”
  • se sta interessando una lista/categoria o più di una

Una volta confermato che si sta ancora verificando, possiamo passare alla raccolta del set minimo di diagnostica per un singolo fallimento recente (Message-ID + l’email grezza memorizzata corrispondente, ecc.).

Non c’è bisogno di scusarsi, sono molto felice che tu stia indagando su questo.

Ciao lavamind - scusa per aver ripreso una vecchia discussione, ma volevo fare un controllo prima di addentrarci ulteriormente nel debugging.

Stai ancora riscontrando i rifiuti Email::Receiver::InvalidPost sul mirroring della mailing list al momento (fine 2025 / inizio 2026)?

Sì, il problema si sta ancora verificando.

all’incirca ogni quanto accade (es. giornalmente / settimanalmente, % dei messaggi)

La frequenza è difficile da definire con precisione, ma il problema interessa almeno diversi messaggi alla settimana, una stima approssimativa forse tra il 5 e il 10% dei messaggi? Alcuni mittenti sembrano essere sovrarappresentati nei log degli errori, quindi almeno non sembra del tutto casuale.

se la “Ragione” dell’email rifiutata è ancora principalmente “Access Denied” rispetto a “topic closed/deleted”

È ancora un mix dei due.

se sta interessando una lista/categoria o più di una

Interessa principalmente la categoria tor-relays, ma questa lista riceve input regolari da mittenti multipli a differenza delle altre liste che replichiamo, le quali ricevono un traffico molto inferiore.

Una volta confermato che si sta ancora verificando, possiamo passare alla raccolta del set minimo di diagnostica per un singolo fallimento recente (Message-ID + l’email raw memorizzata corrispondente, ecc.).

Potremmo dare un’occhiata a questa discussione recente. L’archivio di Mailman indica che ha ricevuto 5 messaggi, ma l’argomento mirror del forum ne ha solo 3 post. I log dei rifiuti contengono 3 errori InvalidPost per questo argomento (2 dallo stesso mittente, stranamente) e per tutti loro la ragione del rifiuto mostrata è “Something has gone wrong. Perhaps this topic was closed or deleted while you were looking at it?” (Qualcosa è andato storto. Forse questo argomento è stato chiuso o eliminato mentre lo stavi guardando?).

Grazie lavamind: questo è un dato molto utile, specialmente avendo un thread concreto “L’archivio di Mailman mostra 5, l’argomento del forum mostra 3” su cui ancorarsi.

Dato che stai riscontrando questo problema diverse volte alla settimana (circa il 5-10% dei messaggi) e che, per questo incidente, il motivo del rifiuto è costantemente la variante fuorviante di “argomento chiuso/eliminato”, il passo successivo migliore è acquisire un messaggio fallito end-to-end in modo da poter vedere cosa stava facendo Discourse.


Per una delle 3 email rifiutate associate a quell’argomento speculare, potresti recuperare quanto segue:

  1. Da /admin/email-logs/rejected, apri una delle righe InvalidPost per quell’incidente e copia:

    • il Message-ID
    • la data/ora
    • il (redatto) A / Da / Oggetto mostrato nella riga
    • il testo completo del motivo del rifiuto (come visualizzato)
  2. Dalla console Rails (nel container dell’app Discourse), estrai l’email grezza che Discourse ha memorizzato:

@supermathie è ancora IncomingEmail il posto canonico per recuperare il grezzo, e c’è qualcos’altro che vorresti oltre ad esso per il debug di InvalidPost?

mid = "<incolla qui il Message-ID dal log delle email rifiutate>"
ie  = IncomingEmail.find_by(message_id: mid)

puts ie&.raw
3. Estrai anche gli attributi `EmailLog` associati per lo stesso Message-ID (questo spesso rivela se Discourse lo ha trattato come una risposta rispetto a un nuovo argomento e quali ID di argomento/categoria ha risolto):
mid = "<lo stesso Message-ID di cui sopra>"

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"
)

Perché questo trio?

  • IncomingEmail.raw ci dice se la mail è arrivata malformata / codificata in modo strano / solo con il piè di pagina, rispetto a Discourse che sceglie la parte MIME “sbagliata”.
  • EmailLog ci dice cosa ha tentato Discourse (nuovo argomento vs risposta, ID di argomento/categoria risolti, ecc.).
  • la riga dell’interfaccia utente dell’email rifiutata conferma che stiamo guardando lo stesso incidente e preserva ciò che gli operatori vedono.

Se la privacy è una preoccupazione, sentiti libero di redigere gli indirizzi e qualsiasi testo del corpo del messaggio all’interno del grezzo, ma per favore mantieni:

  • gli header MIME (Content-Type, boundaries, charset, Content-Transfer-Encoding)
  • la struttura multipart (così possiamo vedere quali parti esistono)
  • il Message-ID e gli header di routing di base (puoi redigere i domini se necessario)

Una volta che abbiamo un Message-ID fallito + IncomingEmail.raw + la porzione EmailLog, dovremmo essere in grado di capire rapidamente se si tratta di:

  • una mancata corrispondenza della chiave di risposta / instradamento dell’argomento,
  • un caso limite di permessi,
  • o un fallimento di analisi dell’email / selezione della parte MIME / decodifica.

Grazie per la guida molto dettagliata!

Concentriamoci su questo messaggio inviato all’argomento della mailing list.

Gli header dell’incidente del log dei messaggi rifiutati mostrano questo:

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

Il testo completo del motivo del rifiuto è questo:

Siamo spiacenti, ma il tuo messaggio email a ["tor-relays@lists.torproject.org"] (intitolato [tor-relays] Re: Questions about running an exit relay) non ha funzionato.

Motivo:

Qualcosa è andato storto. Forse questo argomento è stato chiuso o eliminato mentre lo stavi visualizzando?

Se riesci a correggere il problema, riprova.

Il record in testo semplice dell’email inviata a Discourse da Mailman (IncomingEmail) è disponibile qui (non credo contenga dati che non siano già pubblici, ma in ogni caso ho impostato quel link in modo che scada).

Sfortunatamente, i miei tentativi di estrarre l’EmailLog non hanno prodotto alcun risultato: sembra che Discourse non abbia un record di quel messaggio.

Grazie @lavamind: questo è eccellente (Message-ID + testo di rifiuto + una copia di ciò che Discourse ha memorizzato).

Inoltre: colpa mia per la richiesta di EmailLog - è molto plausibile (e forse previsto) che non ci sia una riga in EmailLog per un rifiuto in entrata come questo. EmailLog è principalmente per la posta in uscita, mentre la posta in entrata risiede in IncomingEmail (che hai già recuperato). @supermathie puoi confermare che non sto mandando la gente nella direzione sbagliata?

Dato che abbiamo l’IncomingEmail, potresti incollare i campi dei metadati da quel medesimo record? Questo ci darà il contesto di “cosa ha cercato di fare Discourse?” che speravo di ottenere da EmailLog.

Nella console Rails:

# @supermathie controllo di sanità: per il debug di InvalidPost in entrata, i metadati di IncomingEmail sono la cosa giusta successiva da raccogliere?
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"
)

# opzionale: se ti senti a tuo agio, anche questo è spesso utile
# (mostra cosa Discourse ha estratto come corpo rispetto a ciò che ha memorizzato grezzo)
pp ie&.attributes&.slice("raw", "cooked")

(Se raw/cooked sono enormi, sentiti libero di ometterli - hai già condiviso il grezzo.)

Perché questi campi sono importanti:

  • topic_id / post_id (se presenti) ci dicono se Discourse ha risolto questo come risposta/nuovo post e cosa ha preso come bersaglio.
  • user_id ci dice a quale utente fittizio/reale Discourse ha mappato il mittente (casi di permessi / “Accesso negato”).
  • error è spesso più specifico del testo generico di rimbalzo “topic chiuso/cancellato”.

Se quegli attributi mostrano che la risoluzione di topic_id/post_id punta al topic speculare, allora il passo successivo probabile è capire perché il destinatario ha deciso che non era valido (corpo estratto vuoto, decodifica MIME, mancata corrispondenza dei permessi, mancata corrispondenza della chiave di risposta, ecc.). Se non mostra alcuna risoluzione di topic/post, ci concentriamo sulle intestazioni di routing / rilevamento della risposta.

E ancora - grazie per il link di incolla. Avere un singolo ID messaggio fallimentare concreto come questo è esattamente ciò di cui avevamo bisogno per smettere di tirare a indovinare.

Sì, è corretto. E sono d’accordo: mostrerà ciò che è stato ricevuto, quali associazioni Discourse è stata in grado di stabilire e, si spera, indicherà il passo successivo.

1 Mi Piace

Ecco i campi di metadati per l’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"}

Per quanto riguarda i contenuti raw/cooked, solo la proprietà raw contiene l’email completa con le intestazioni. La proprietà cooked non esiste nell’oggetto.

[quote=“lavamind, post:13, topic:377793”]Il record in testo semplice dell’email inviata a Discourse da Mailman (IncomingEmail) è disponibile qui
[/quote]

Eseguendo quello tramite Email::Receiver.new(rawmessage).select_body restituisce:

=> ["", "", 2]

quindi sono abbastanza sicuro che ciò che sta accadendo qui è che Discourse sta selezionando in modo errato una porzione di testo semplice vuota come corpo del messaggio, probabilmente questa:

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


che sarebbe un post non valido.

Dovremo indagare un po’ su questo e probabilmente usarlo come caso di test.

La mail ha la seguente struttura:

* #<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

(sì, ci sono tre copie del contenuto effettivo, contenuto vuoto e la firma PGP)

Quella prima parte text/plain viene aggiunta dal software della mailing list e appare così:

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

Questo è ciò che Discourse (in realtà, la gem mail tramite .text_part) sta scegliendo come contenuto del messaggio:

> 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

e viene trattato come un corpo vuoto con una firma omessa.

Se non fosse per questa parte per lo più vuota aggiunta dalla mailing list, Discourse avrebbe estratto il seguente contenuto per il post:

> 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...

Quali dati hanno richiesto?

> 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.

Ti possono negare di spegnere il relay?
In tal caso, potresti gestire un nuovo "sistema" su un altro IP.

(parte omessa sotto)

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

-- 
cordiali saluti
Marco

Send spam to abfall1767375998@stinkedores.dorfdsl.de

Non riesco davvero a trovare colpe nella gestione della posta di Discourse: se dovessi attribuire la colpa, probabilmente inizierei dal software della mailing list per aver effettivamente aggiunto contenuto vuoto all’inizio. Sarebbe stato più appropriato metterlo alla fine, dopo il messaggio reale.

Avrebbe funzionato con la gem Mail e avrebbe anche un aspetto migliore nei client di posta: ecco come appare in Thunderbird come ricevuto originariamente:

e la mia versione “corretta” (test-fixed.eml.txt (14.3 KB))
con la firma della mailing list in fondo invece che in cima:

Ho contattato un (umano) iscritto a quella lista e ecco come appare il corpo del messaggio grezzo nel suo MUA con alcune intestazioni filtrate:

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==--

Non c’è duplicazione e le parti sono ordinate correttamente. Mi aspetterei che questo sia più vicino a ciò che Mailman invia effettivamente agli iscritti alla lista, altrimenti se la maggior parte delle persone ricevesse messaggi con il piè di pagina in alto, forse lo sapremmo?

Mi chiedo quindi se qualcos’altro nella pipeline di elaborazione possa star modificando il corpo del messaggio. Il nostro server Discourse elabora prima le email in arrivo tramite Postfix che è configurato per passarle a un container mail-receiver, che a sua volta le passa al container Discourse.

Oh! Dato questo sono tornato a indagare di nuovo… e si scopre che è un nostro problema dopotutto.

Dall’email grezza che hai pubblicato sopra, ho appena scoperto che IncomingEmail.raw non memorizza l’email grezza… la elaboriamo prima con Email::Cleaner.

Questo sembra essere colpa della gem di posta di Ruby… riordina le parti di un messaggio di posta quando lo riscrive:

[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>>
]

il che causa il problema:

[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»
Dettagli della differenza

test.eml: messaggio grezzo come fornito
test-rubyparsed.eml: messaggio analizzato da ruby e poi riconvertito in una stringa
test-pythonparsed.eml: messaggio analizzato da python e poi riconvertito in una stringa

--- 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,6 +69,7 @@
  --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 Mi Piace