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.