- Shipped
- 5 de agosto de 2026 às 01:33 UTC
- Author
- Kamo
- Commit
- 2fda4ac
Cada e-mail transacional que enviamos com um logotipo org inlined chegou em nosso próprio /mensages visualizador com um assunto correto e um corpo completamente vazio. isAttachmentPart() tratou qualquer parte carregando um Conteúdo-ID como um anexo. A texto/html ROOT de uma multiparte/relacionado tem um por design — applyInlineRelated Conteúdo define-o para que o parâmetro RFC 2387 start= possa apontar para o corpo, que é o que permite gateways mais rigorosos e Outlook encontrá-lo. Então walkParseMultipart classificou o corpo como um anexo e continuou passando por ele antes de chegar ao texto/html ramo corpo-candidato. htmlBody permaneceu nulo, e porque um envio relacionado carrega não text/plain alternativa, textBody também era nulo — o espectador não tinha nada para renderizar. Verificado contra a mensagem entregue em vez de inferido: o ficheiro maildir bruto possui uma multi-parte bem formada/relacionada com uma raiz completa de 4329-bytes de texto/html (Content-ID <emailroot>, 7bit, limites intactos) e dois PNGs em linha base64. A a mensagem nunca foi o problema; o leitor foi. Isto era invisível até agora porque o correio transacional sem logotipos em linha é enviado como uma mensagem simples não-multipart text/html, que getMessage() lida com `conteúdo instância de String` caminho e nunca consulta éAtaqueParte em tudo. A regra Content-ID ainda é válida para tudo o que não é um corpo de texto, então o inline logos ficar listado e cid: referências continuam resolvendo. Testes analisam MIME RAW em vez de montar peças com setContent — que não escreva o cabeçalho Tipo de Conteúdo até que a mensagem anexa seja salva, então uma reunião part reports text/plain and every isMimeType("text/html") branch silenciosamente falta. A fixture que mente sobre o único cabeçalho que esta lógica liga teria passado contra o código quebrado. Confirmado: 4 dos 6 falham sem a correção.