ZMS-217 Fix message-splitter trailing line breaks being incorrectly broken into separate lines#31
Conversation
|
Hi, |
|
@GioPan04 we’ll return to this once @NickOvt is back from vacation. The core issue is that most clients buffer outgoing data and send it in large chunks (for example, 64 kB). PHP, however, writes directly to the TCP socket, so bytes are sent exactly as you output them. With a single 64 kB chunk, it’s very unlikely that the chunk ends on the CRLF boundary that triggers the mailsplit bug. When you send 2 B + 100 B + 24 B instead, the chance that one of those smaller chunks ends on such a boundary, and therefore triggers the bug, becomes much higher. |
|
Hello! @GioPan04 I think that this fix in this PR has not been reverted by the PR you have linked here. The Titanism's PR addresses wildducks message splitter which (although very similar) is a bit different from generic mailsplit. And that PR has not yet been merged (nor properly reviewed/tested). As Andris has mentioned this PR was made to address the issue of inconsistent chunks (mainly in PHPmailer). The PR you have mentioned will be reviewed by me probably in the next week or two. Cheers! 🌟 |
|
Hi @NickOvt , hope the vacation went well! Anyway, about this PR, I think I wasn't clear in my last message. I'm not interested in the wildduck PR, I was referring to it because, if I understood correctly, this PR broke something, and had to be reverted in #32. |
|
Oh I didn't notice the revert at first. I do suppose I'll reimplement this PR but highly likely differently than before |
|
Okay, perfect. Thank you so much! |
3 participants
/ror/nor/rbody>instead of/r/n<body>). The issue was especially noticeable if the input chunks fed to the splitter were in the range of 2-8 in size.message-splitter-testsrewritertest to account to new hash. The hash is calculated based onMessageJoinerobjects and thus with the new fix the joiner objects differ slightly from the previous logic - resulting in a different hash.