- Spegnimento
- 5 agosto 2026 alle ore 01:33 UTC
- Autore
- Kamo
- Impegno
- 2fda4ac
Ogni email transazionale che inviamo con un logo org in linea è arrivato nel nostro /messages spettatore con un soggetto corretto e un corpo completamente vuoto. isAttachmentPart() trattata QUALSIASI parte che trasporta un Content-ID come allegato. The testo/html ROOT di un multipart/correlato ha uno per design — applicareInlineRelated Contenuto imposta in modo che il parametro RFC 2387 start= può puntare sul corpo, che è ciò che consente gateway più rigorosi e Outlook lo trovano. Così walkParseMultipart classificato il corpo come un allegato e continuava a superarlo prima di raggiungere il testo/html ramo del corpo-candidate. htmlBody rimase null, e perché un invio relativo non porta text/plain alternativa, textBody era null troppo — lo spettatore non aveva nulla da rendere. Verificato contro il messaggio consegnato piuttosto che inferred: il file maildir raw tiene una multipart/ ben formata con una radice completa di 4329 byte text/html (Content-ID <emailroot>, 7bit, confini intatti) e due PNG in linea base64. The il messaggio non era mai il problema; il lettore era. Questo è stato invisibile fino ad ora perché la posta transazionale senza loghi in linea è inviato come messaggio SIMPLE non-multipart text/html, che getMessage() gestisce "l'istanza di contenuto di String" percorso e non consulta mai èAttachmentPart affatto. La regola Content-ID tiene ancora per tutto ciò che non è un corpo di testo, quindi la i loghi inline rimangono elencati e cid: i riferimenti continuano a risolvere. Test parse RAW MIME piuttosto che assemblare parti con setContent — che non scrivere l'intestazione Contenuto-Tipo fino a quando il messaggio di chiusura non viene salvato, quindi un assemblato parte riferisce testo / cappella e ogni èMimeType("text/html") ramo silenziosamente manca. A fissazione che sta circa l'intestazione che questa logica accenderebbe sarebbe passata contro il codice rotto. Confermato: 4 dei 6 falliscono senza la correzione.